SIP Tutorial

Introduction to SIP

Original Slides by Alan Johnston and Henry Sinnreich, MCI (at VON03)
 Contents

SIP Overview
SIP in detail
SIP Call Flow Scenarios
SIP Security
SIP Programming
Some Related Works

2
 SIP Overview

What SIP is, Multimedia Protocol

Stack, Short History and Related
Protocols are included.
 Why packet switching? Why SIP?

100
90
80
70
60 electromech
50 analog
40 digital
30
20
10
0
1980 1985 1987 1990 1995 2000 2001

Technology evolution of PSTN

4
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.

5
 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

6
Internet Multimedia Protocols

RTSP

7
 A Short History of SIP
Internet Engineering Task Force (IETF) protocol
Inventors: M. Handley, H. Schulzrinne, E. Schooler,
and J. Rosenberg
Became Proposed Standard and RFC 2543 in March
1999 in MMUSIC WG.
Separate SIP WG established in September 1999.
Now new SIPPING (applications) and SIMPLE
(presence and instant messaging) WGs using SIP.
RFC2543bis-09 I-D became RFC 3261 in June 2002
Added four new authors: G. Camarillo, A. Johnston, J.
Peterson, and R. Sparks.
Entire spec rewritten for clarity, but some new features
Mostly backwards compatible with RFC 2543

8
 SIP Requests and Responses

SIP Request types are SIP Responses use a

called methods numerical code and a
reason phrase
Methods in base spec:
Classes:
INVITE
1xx Informational
ACK 2xx Final
OPTIONS 3xx Redirection
CANCEL 4xx Client Error
BYE 5xx Server Error
REGISTER 6xx Global Failure
Example: 404 Not Found

9
 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
10
 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.

11
 SIP Uniform Resource Indicators (URIs)
Same form as email addresses: user@domain
Two URI schemes:
sip:henry@siptest.mci.com is a SIP URI
Most common form introduced in RFC 2543
sips:henry@siptest.mci.com 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)
sip:henry@mci.com (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)
sip:henry@127.24.45.4 or sip:henry@cube43.lab.mci.com
(Which needs no resolution for routing)
12
 SIP Trapezoid
DNS Server Location
Server

DNS

SIP
Outbound Inbound
Proxy Server Proxy Server

SIP
SIP

SIP

Media (RTP)

User Agent A User Agent B

13
 SIP Elements User Agents
DNS Server Location
Capable of sending
Server and receiving SIP
requests.
DNS UAC User Agent Client
UAS User Agent Server
End Devices
SIP
Outbound Inbound SIP phone
Proxy Server Proxy Server
PC/laptop with
SIP Client
SIP
PDA
SIP
mobile phone
SIP PSTN Gateways
Media (RTP) are a type of User
Agent
User Agent A
User Agent B

14
 SIP Elements Proxy Servers
DNS Server Location
Server Forward or proxy
requests on behalf of
DNS User Agents
Consult databases:
SIP DNS
Outbound Inbound
Proxy Server Proxy Server Location Server
Types:
SIP Stateless
Transaction Stateful
SIP

Call Stateful
SIP
No media capabilities
Media (RTP)
Ignore SDP.
User Agent A User Agent B Normally bypassed once
dialog established, but
can Record-Route to
stay in path.
15
 SIP Elements Other Servers
DNS Server Location
Server
Location Server

DNS
Database of locations of
SIP User Agents
SIP Queried by Proxies in
Outbound Inbound
Proxy Server Proxy Server routing
Updated by User Agents
SIP by Registration
SIP

SIP DNS Server

Media (RTP)

User Agent A User Agent B SRV (Service) Records

used to locate
Inbound Proxy
Servers
16
 SIP Client and Server
SIP Elements are either
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)

17
 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)

18
 SIP Registrar, 2
SIP Registrars store the location of SIP
endpoints
Each SIP endpoint Registers
with a Registrar using its Address of Record and Contact
address
Address of Record for John Smith in From: header
From: John Smith <sip:jsmith@zultys.com
Contact: header tells Registrar where to send messages
Contact: John Smith <sip:jsmith@192.168.1.100>
SIP Proxies
query SIP Registrars for routing information
Incoming calls addressed to sip:jsmith@zultys.com
now routed by the Proxy to the Contact: header URL
sip:jsmith@192.168.1.100

19
 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

20
 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

21
 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

22
 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

23
 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

24
 SIP in detail

Now, we are going to study SIP in

detail including SIP Request, SIP
Response and SIP Header
 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

26
 SIP Request Methods, 2
REGISTER
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 Voicemail)

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

28
 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

29
 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

30
 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

31
 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.

32
 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

33
 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. Request-URI

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

(Alice's SDP not shown)

34
 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: sip:john@company.com;tag=123456

35
 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

36
 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

37
 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 101-199 may be sent
reliably and acknowledged with PRACK
If no PRACK sent, response retransmitted
Defined in RFC 3262

38
 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 voicemail
Defined in RFC 3265

39
 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

40
 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

41
 SIP Responses: 1xx-3xx
SIP Response Code
100 Trying
180 Ringing
181 Call Is Being Forwarded
182 Queued
183 Session Progress
200 OK
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
Brief Description
Request received and action is being taken
UA received INVITE and is alerting user
Used by proxy to indicate call is being forwarded
Called party unavailable, call queued
Used in early media and QoS setup
Request successful
Address resolved to several choices
User can no longer be found at Req-URI address
Temporarily cannot find user at Req-URI address
Resource MUST be accessed through proxy.
Call not successful. Alternatives possible.
42
 SIP Responses: 4xx
SIP Response Code
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
410 Gone
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
420 Bad Extension
421 Extension Required
423 Registration Too Brief
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
491 Request Pending
493 Undecipherable
Brief Description
Request not understood due to malformed syntax
Request requires user authentication
Reserved for future use
UAS understood request and refuses to fulfill it
UAS finds that user doesn't exist in the domain
Method is understood but not allowed
Response content not allowed by Accept header
Client must first authenticate itself with proxy
UAS could not produce response in time
UAS resource unavailable; no forwarding addr.
Request contains body longer than UAS accepts
Req-URI longer than server is willing to interpret
Format of the body not supported by UAS
Scheme of URI unknown to server
UAS not understand protocol extension
UAS needs particular extension process request
Contact header field expiration time too small
UAS contacted successfully but user unavailable
UAS Rx request not matching any existing dialog
UAS has detected a loop
UAS received request containing Max-Forwards=0
UAS Rx request with incomplete Request-URI
The Request-URI was ambiguous
UAS contacted successfully but user busy
Request terminated by a BYE or CANCEL request
Same as 606 but only applies to addressed entity
UAS Rx req. & have pending req. for same dialog
UAS Rx request with encrypted MIME body & not have decryption key
43
 SIP Responses: 5xx-6xx
SIP Reponse Code
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
Brief Description
UAS unexpected condition & cannot fulfill request
UAS not support functionality to fulfill the request
UAS Rx invalid response from a downstream server
UAS can't process due to overload or maintenance
UAS not Rx response from external server
UAS not support SIP version in request
Message length exceeded UAS capabilities
End systems contacted, user busy at all of them
End systems contacted, user explicitly decline
UAS has information Req-URI user not exist
Some aspects of Session Desc. not acceptable
44
 SIP Message Details
INVITE sip:wh@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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
sip:wh@200.201.202.203
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
45
 SIP Headers
SIP Requests and Responses contain Headers (similar
to Email headers)
Required Headers
To
From
Via
Call-ID
CSeq
Max-Forwards
Optional Headers:
Subject, Date, Authentication (and many others)

46
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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.
47
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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.

48
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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
49
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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

50
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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

51
 SIP Message Details
INVITE sip:w.h@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
Max-Forwards: 69
To: Heisenberg <sip:w.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:schroed5244@100.101.102.103
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).
52
 SDP Message Body Details
v=0
o=Tesla 289084526 28904529 IN IP4 lab.high-voltage.org
s=-
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Version number (ignored by SIP)

Origin (only version used by SIP - 28904529)
Subject (ignored by SIP)
Connection Data (IP Address for media - 100.101.102.103)
Time (ignored by SIP)
Media (type - audio, port - 49170, RTP/AVP Profile - 0)
Attribute (profile - 0, codec - PCMU, sampling rate 8000 Hz)

53
 SIP Response Details
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK8542.1
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76
To: Heisenberg <sip:w.heisenberg@munich.de>;tag=24019385
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345
Call-ID: 105637921@100.101.102.103
CSeq: 1 INVITE
Contact: sip:wh@200.201.202.203
Content-Type: application/sdp
Content-Length: 173

v=0
o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203
s=SIP Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 56321 RTP/AVP 0
a=rtpmap:0 PCMU/8000

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.
54
 SIP Call Flow Scenarios
As followings
 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.

56
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

1. A dials SIP AOR

URI sip:B@mci.com.
Outbound Inbound User Agent A sends
Proxy Server
Proxy Server INVITE to outbound
Proxy Server.
1. INVITE
Contact: A
SDP A
2. 100 Trying 2. Outbound Proxy
sends 100 Trying
response.

User Agent A User Agent B

(Not Signed In)

57
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 1.2.3.4

3. Outbound Proxy does
mci.com?

DNS query to find

Outbound Inbound proxy server for
Proxy Server Proxy Server
mci.com domain

1. INVITE
4. DNS responds with
Contact: A 2. 100 Trying IP address of
SDP A
mci.com Proxy
Server

User Agent A User Agent B

(Not Signed In)

58
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: mci.com? 4. Response:

1.2.3.4
5. Outbound Proxy
5. INVITE sends INVITE to
Outbound
Contact: A
SDP A Inbound Inbound Proxy
Proxy Server Proxy Server
Server.
6. 100 Trying
6. Inbound Proxy sends
1. INVITE
Contact: A 2. 100 Trying 100 Trying
SDP A
response.

User Agent A User Agent B

(Not Signed In)

59
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: mci.com? 4. Response:

1.2.3.4 7. LS Query: B? 8. Response: Not
Signed In
7. Inbound Proxy
5. INVITE
Contact: A consults Location
SDP A Inbound
Outbound
Proxy Server Proxy Server Server.
6. 100 Trying 8. Location Server
1. INVITE
Contact: A
responds with Not
2. 100 Trying
SDP A Signed In.

User Agent A User Agent B

(Not Signed In)

60
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 7. LS Query: B? 8. Response:

mci.com? 1.2.3.4 Not Signed
In 9. Inbound Proxy sends
5. INVITE
Contact: A
480 Temporarily
Outbound
SDP A Inbound Unavailable
Proxy Server
Proxy Server 6. 100 Trying response.
1. INVITE
Contact: A
9. 480 Temporarily Unavailable 10. Outbound Proxy sends
SDP A 10. ACK ACK response.
2. 100 Trying

User Agent A User Agent B

(Not Signed In)

61
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

3. DNS Query: 4. Response: 7. LS Query: B? 8. Response:

mci.com? 1.2.3.4 Not Signed
In
5. INVITE
Contact: A 11. Outbound Proxy
Outbound
SDP A Inbound forwards 480 response
Proxy Server
Proxy Server 6. 100 Trying to A.
1. INVITE 9. 480 Temporarily Unavailable 12. A sends ACK response.
Contact: A
SDP A 10. ACK
2. 100 Trying
11. 480 Temporarily Unavailable
12. ACK

User Agent A User Agent B

(Not Signed In)

62
 SIP Presence Example
DNS Server
Presence
Server

3. SUBSCRIBE
1. A wants to be informed
when B signs on, so
Outbound
2. SUBSCRIBE Inbound sends a SUBSCRIBE
Proxy Server Proxy Server
2. Outbound Proxy
forwards to Inbound
1. SUBSCRIBE
Proxy
3. Inbound Proxy forwards
to Bs Presence Server

User Agent A User Agent B

(Not Signed In)

63
 SIP Presence Example
DNS Server
Presence
Server

3. SUBSCRIBE 4. 200 OK

4. Presence Server
Outbound
2. SUBSCRIBE Inbound authorizes subscription
Proxy Server
Proxy Server 5. 200 OK by sending a 200 OK.
5. & 6. 200 OK proxied
1. SUBSCRIBE 6. 200 OK
back to A.

User Agent A User Agent B

(Not Signed In)

64
 SIP Presence Example
DNS Server
Presence
Server

7. NOTIFY 12. 200 OK

<Not Signed In>
7. Presence Server sends
8. NOTIFY NOTIFY containing
<Not Signed In>
Outbound Inbound current presence status
Proxy Server Proxy Server
11. 200 OK of B (Not Signed In).
8. and 9. NOTIFY is
9. NOTIFY
<Not
10. 200 OK
proxied back to A.
Signed
In> 10. A acknowledges receipt
of notification with
200 OK.
11. & 12. 200 OK is
User Agent A User Agent B
proxied back to Bs
(Not Signed In) Presence Server.

65
 SIP Registration Example
DNS Server
Location
Server

2. Update database:
B = B@2.3.4.5
1. B signs on to his SIP
Phone which sends a
Outbound Outbound REGISTER message
Proxy Server
Proxy Server containing the FQDN
URI of Bs User Agent.
2. Database update is sent
1. REGISTER
Contact: B@2.3.4.5 to the Location Server

User Agent A User Agent B

66
 SIP Registration Example
DNS Server
Location
Server

2. Update database:
B = B@2.3.4.5 3. OK
3. Location Server
database update is
confirmed.
Outbound Outbound
Proxy Server Proxy Server 4. Registration is confirmed
with a 200 OK
response.
1. REGISTER 4. 200 OK
Contact: B@2.3.4.5 Contact: B@2.3.4.5

User Agent A User Agent B

67
 SIP Presence Example
DNS Server
Presence
Server

13. Presence Server learns

13. NOTIFY
<Signed In> 18. 200 OK of Bs new status from
the Location Server and
14. NOTIFY sends a NOTIFY
Outbound
<Signed In> Inbound containing new status
Proxy Server
Proxy Server 17. 200 OK of B (Signed In).
14. & 15. NOTIFY is
15. NOTIFY
<Signed In> 16. 200 OK proxied back to A.
16. A acknowledges receipt
of notification with 200
OK.
17. & 18. 200 OK is
User Agent A User Agent B
proxied back to
Presence Server.

68
 SIP Instant Message Scenario
DNS Server
1. A sends an Instant
Location
Server Message to B saying
Can you talk now?
3. LS Query: B? 4. Response: in a MESSAGE
sip:B@2.3.4.5
request.
2. MESSAGE
<Can you
2., 3. & 4. MESSAGE
Outbound
talk now?> Inbound request is proxied,
Proxy Server
Proxy Server Location Server
7. 200 OK
queried.
1. MESSAGE
<Can you 5. MESSAGE 5. Inbound Proxy
talk now?> 8. 200 OK <Can you 6. 200 OK forwards MESSAGE to
talk now?>
B.
6. User Agent B responds
with 200 OK.
7. & 8. 200 OK is proxied
User Agent A User Agent B
back to A.

69
 SIP Instant Message Scenario
Location
1. B sends an Instant
DNS Server
Server Message to A saying
Sure. in a
5. LS Query: A? 6. Response: 2. DNS Query:
sip:A@4.5.3.2 globalipcom.com?
3. Response: 5.6.7.8 MESSAGE sent to As
AOR URI.
4. MESSAGE
2. & 3. DNS Server is
Inbound
<Sure.> Outbound queried.
Proxy Server Proxy Server
4. Outbound Proxy
9. 200 OK
forwards MESSAGE to
7. MESSAGE
<Sure.> 8. 200 OK Inbound Server.
1. MESSAGE
<Sure.>
10. 200 OK 5. & 6. Location Server is
queried.
7. Inbound Proxy
forwards to A.
User Agent A User Agent B
8. User Agent A responds
with 200 OK.
9. & 10. 200 OK is proxied
back to B.
70
 SIP Call Setup Attempt Scenario
DNS Server Location
Server

1. to 5. A retries
5. LS Query: B 6. Response:
sip:B@2.3.4.5
INVITE to B which
routes through two
3. INVITE
Contact: A Proxy Servers.
SDP A Inbound
Outbound
Proxy Server 6. Location Server
Proxy Server
4. 100 Trying
responds with the
1. INVITE
FQDN SIP URI of Bs
Contact: A 2. 100 Trying 7. INVITE SIP Phone.
SDP A
Contact: A
SDP A 7. Inbound Proxy Server
forwards INVITE to
Bs SIP Phone.

User Agent A User Agent B

71
 SIP Call Setup Scenario
DNS Server Location
Server

8. User Agent B alerts B

9. 180 Ringing
and sends 180
Inbound
Outbound
Proxy Server Ringing response.
Proxy Server
9. & 10. 180 Ringing
is proxied back to A.
10. 180 Ringing
8. 180 Ringing

User Agent A User Agent B

72
 SIP Call Setup Scenario
DNS Server Location
Server

11. B accepts call and

9. 180 Ringing
Inbound User Agent B sends
Outbound
Proxy Server Proxy Server 200 OK response.
12. 200 OK
Contact: B 12. & 13. 200 OK is
SDP B
10. 180 Ringing 13. 200 OK 11. 200 OK proxied back to A.
Contact: B 8. 180 Ringing Contact: B
SDP B SDP B

User Agent A User Agent B

73
 SIP Call Setup Scenario
DNS Server Location
Server

14. ACK is sent by A to

9. 180 Ringing confirm setup call
Outbound Inbound
Proxy Server Proxy Server bypassing proxies.
12. 200 OK
Contact: B
SDP B
10. 180 Ringing 13. 200 OK 11. 200 OK
Media session begins
Contact: B
SDP B
8. 180 Ringing Contact: B
SDP B
between A and B!
14. ACK

Media (RTP)

User Agent A User Agent B

74
 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
Outbound Inbound 200 OK.
Proxy Server
Proxy Server
17. B sends ACK to A.

No media between A
15. INVITE
SDP a=sendonly and B.
16. 200 OK
SDP A

17. ACK
User Agent A User Agent B

75
 SIP Call Transfer Scenario
DNS Server Location
Server

18. B transfers A to C
Outbound Inbound
Proxy Server
using REFER.
Proxy Server
19. Transfer is accepted
by A with 202
Accepted response.
20. Notification of
18 REFER Refer-To: sip:C@mci.com
trying transfer is
19. 202 Accepted
sent to B in NOTIFY.
20. NOTIFY <100 Trying>
User Agent A
21. B sends 200 OK
21. 200 OK User Agent B
response to NOTIFY

76
 SIP Call Transfer Scenario
DNS Server Location
Server

1. to 5. A sends new
5. LS Query: C? 6. Response: INVITE to C which
sip:C@6.7.8.9
3. INVITE routes through two
Contact: A
Ref-By: B Proxy Servers.
SDP A Inbound
Outbound
Proxy Server Proxy Server 6. Location Server
4. 100 Trying responds with the
1. INVITE
7. INVITE FQDN SIP URI of Cs
Contact: A
Contact: A 2. 100 Trying Ref-By: B SIP Phone.
Ref-By: B SDP A
SDP A 7. Inbound Proxy Server
User Agent C forwards INVITE to
Cs SIP Phone.

User Agent A User Agent B

77
 SIP Call Transfer Scenario
DNS Server Location
Server
8. User Agent C alerts C
and sends 180
Ringing response.
9. & 10. 180 Ringing
9. 180 Ringing
Inbound
is proxied back to A.
Outbound
Proxy Server Proxy Server
11. C accepts call and
12. 200 OK
Contact: C 11. 200 OK sends 200 OK
SDP C Contact: C
10. 180 Ringing
13. 200 OK SDP C response.
Contact: C 8. 180 Ringing
SDP C 12. & 13. 200 OK is
14. ACK
proxied back to A.
User Agent C
Media (RTP) 14. ACK is sent by A to
confirm setup call.
User Agent A
User Agent B
Media session between
A and C begins.
78
 SIP Call Transfer Scenario
DNS Server Location
Server

20. Notification of
successful transfer is
sent to B in NOTIFY.
Outbound Inbound 21. B sends 200 OK
Proxy Server
Proxy Server
response to NOTIFY
22. B hangs up by
sending a BYE.
23. 200 OK response to
20. NOTIFY <200 OK> BYE is sent.
21. 200 OK
22. BYE
User Agent A User Agent B
23. 200 OK

79
SIP Security
 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 cant 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

81
 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.

82
 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

83
 Attacks
IPhreakers
IP knowledge
Known weaknesses
Evolution 2600Hz -> voicemail/intl GWs -> IP telephony
Internal or external threat ?
Targets: home user, enterprise, government, etc ?

Protocol implementations
PROTOS

The human element

84
 Attacks : denial of service
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

85
 Attacks : fraud

Call-ID spoofing

User rights takeover

Fake authentication server

Effects
Access to voicemail
Value added numbers
Social engineering
Replay

86
 Attacks: interception
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

87
 Attacks : systems
Systems
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

88
 Defense
Signaling: SIP
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

89
SIP Programming
 SIP based Application Interfaces
These include :
JAIN SIP
Low level and very complex API
CNRSIP API is one of available reference implementations.
SIP Servlets
proposed within JAIN
SIP API for J2ME
intermediate level API (minimal SIP knowledge required)
SIP CGI
CPL ( Call Processing Language)
XML based

91
 HTTP Servlets
HTTP Java Servlets Widely Used in Web
HTTP Servlets
Application Development War File

Applications Consist of Sets of HTTP

Servlets, Each of Which Processes a
Single Web Request in the Application

HTTP Servlets Return Web Pages to

Developer
Display
Deployer
HTTP Servlets Can Create Session Data
e.g., shopping cart, that spans multiple
requests

Container Manages HTTP Servlet Web Server

Lifecycles, Fault Tolerance, Session State

HTTP Servlets Collected into a War File

Web Archive

92
 SIP Servlet API
Java extension API for SIP servers
Similar in spirit to HTTP servlet API
Server matches incoming messages against local rules in order to
decide which servlet to pass message to
The API gives full control to servlets to handle SIP messages, e.g.
has full access to headers and body
proxy or redirect requests
respond to or reject requests
forward responses upstream
initiate requests
Servers may choose to provide constrained environment to
selected servlets (e.g. using sandbox security model)

93
 Basic SIP Servlet Model

servlet servlet

Servlet Engine
requests requests
SIP Server
responses responses

Location of SIP Server and servlet

engine:
in same Java Virtual Machine
different process, same host
different hosts: 1:1, 1:n, n:1, n:m
94
 Example: Routing Services

RTP

servlet
UAC UAS

Server
SIP SIP

Servlet proxies request to one or more destinations

- forwards response to caller

95
 Example: Servlet as UAS

RTP
servlet
UAC
Server
SIP

Servlets can reject (screen) calls

Can accept and set up media streams

96
 Benefits of Servlet Model
Powerful:
Full access to SIP signaling
Performance:
No need to fork new process for each request
The same servlet can handle many requests simultaneously
Safety: type checked; no pointers; exception handling
Convenience:
high level abstractions.
Tight integration with server: logging, security, location database
Lifecycle model allows servlets to
maintain state, e.g. database connections
manage timers
Access to wide range of APIs

97
 An Example: RejectServlet
import org.ietf.sip.*;

public class RejectServlet extends SipServletAdapter {

protected int statusCode, reasonPhrase;

public void init(ServletConfig config) {

super.init(config);
try {
statusCode = Integer.parseInt(getInitParameter("status-code"));
reasonPhrase = getInitParameter("reason-phrase");
} catch (Exception _) {
statusCode = SC_INTERNAL_SERVER_ERROR;
}
}
public boolean doInvite(SipRequest req) {
SipResponse res = req.createResponse();
res.setStatus(statusCode, reasonPhrase);
res.send();
return true;
}
}

98
 Relationship to JAIN SIP
JAIN SIP is a generic, low-level
interface for accessing SIP

Servlet
Servlet
services
Can be used in
Clients SIP Servlet API
Servers
Gateways
SIP Servlet
Focuses purely on the protocol
Container
JAIN SIP
Complete access to SIP
capabilities
SIP Protocol
Supports transactions only
SIP Servlet Container is a
particular application of JAIN
SIP

99
 Relationship to JAIN SIP
Servlets focus on high Hide many parts of JAIN SIP
volume carrier grade servers Direct access to many
Add significant, non-SIP headers is not provided
protocol functions Write access to most
Lifecycle management everything is often
Domain objects restricted
Context and configuration Servlets should be defined to
Deployment descriptors allow a SIP container to be
Archive files built using JAIN SIP
Synchronization primitives SIP Objects in Servlet API
Security defined with interfaces that
Add significant SIP protocol match JAIN SIP signatures
functions Cannot directly expose JAIN
Construction of requests SIP objects, though
and responses from domain
objects
100
 SIP CGI

Almost identical to HTTP CGI

Language independent ( Perl, Tcl, C, C++, ... )
Any binary may be executed as a separate program

Suitable for services that contains substantial web content

Passes message parameters through environmental variables to

a separate program.
More flexible but more risky

Feb. 1, 2001: RFC 3050 (Common Gateway Interface for SIP)

published

101
 Call Processing Language (CPL)

Designed by the IETF to support sophisticated telephony

services
May be used by both SIP or H.323.
XML based scripting language for describing controlling call
services
Simple Syntax
Extendible
Easily edited by GUI tools
Scripts runs on network SIP signaling server to create end user
services
Lightweight CPL interpreter is need to parser & validate scripts

102
 CPL Example

A simple script that blocks anonymous callers

<?xml version="1.0" ?>

<!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN"
"cpl.dtd">
<cpl>
<incoming>
<address-switch field="origin" subfield="user">
<address is="anonymous">
<reject status="reject"
reason="I don't accept anonymous calls" />
</address>
</address-switch>
</incoming>
</cpl>

103
 Some Related Works

Parlay
IMS
IPv6
 Why Parlay is Important to Galaxy

Open standard
Range of services
Many levels of sophistication and complexity
Secure framework for discovery of and access to
services by third party applications
Registration of non-Parlay service APIs
Independent of specific network and software
environment

105
 Why Unified Communications?

Calls Messages
Private Job Job Private

Fixed Fax

E-mail
Mobile

SMS
VoIP
V-mail
MPEG

IM
106
 Architecture I:
Parlay as a Unifying Technology

Application

Parlay

INAP

ISUP
MAP
SIP

107
 Architecture II:
SIP as a Unifying Technology

Application
Servlet/CGI/CPL Script
SIP
Other Networks
Gateway to

IP network
108
 Key Questions
Which of these two models is correct, or are there
opportunities for both approaches to co-exist?
How well can a generic network API sit on top of
SIP? For example, would it severely limit a developer,
and what advantages would it offer?
Which aspects of network functionality will actually
be useful in practice to developers?

109
 Parlay within Galaxy

BT C++ BT VB PSTN
3rd Party Apps Apps Platform
Applications CORBA DCOM

Appium
Unified Parlay Gateway
Comms
Application

SIP Proxy VOIP gateway

SIP clients

110
Feasibility: A proof of concept prototype ...

Game server
Parlay

Game events
XML over JXTA MRFC MRFP

SIP RTP

Player 1

Player 2 Player 3

111
 Some Challenges for Parlay
Which technologies should Parlay support?
How can interoperability testing be encouraged?
How can Parlay get feedback from developers?
Sizeable specifications with complex interfaces and data types
give long learning curve for developers?
Although specifications are maturing, still few Parlay products
commercially available. Why?
How does Parlay keep pace with new protocols?

112
 Parlay on a SIP Network ?
Parlay adds security to SIP
Parlay provides many features not available in SIP APIs
Parlay provides a network independent model

BUT...
SIP APIs can make some simpler solutions for some applications
envisaged by Parlay group
Parlay could support SIP better

SO...
SIP will have a significant impact on the future of Parlay
SIP and Parlay can already work well together and are a
powerful combination

113
Global SIP/IMS deployment needs IPv6
Introduction of SIP-based peer-to-peer services is an important
step after current client-server based services.
IP Multimedia Subsystem (IMS) is a service infrastructure based
on the use of Session Initiation Protocol (SIP).
3GPP Release 5 and 6 specifications
3GPP2 specifications
In order to make peer-to-peer services work between different
operators' networks, IPv6 is needed - peer-to-peer services work
well only with public IP addresses.
Small scale IMS deployment / piloting can be started with IPv4.
IPv6 is vital for wider scale, global IMS deployment.

114
Example of peer-to-peer IP connectivity
UMS CSCF Thomas
challenges
you to a
game of
checkers!

Peter: 00:00:00
Accept
Thomas:Decline
00:00:00

SIP IPv6
Game data

IP Connection
Thomas
Peter
Peter accepted Invite
the challenge! player

Chat

Push to
Stream

Quit

115
Example of peer-to-peer IP connectivity
UMS CSCF > Peter: I am
going to win
this time!
>Thomas:
Yeah right, in
your dreams!

Peter: 00:00:00
Thomas: 00:00:00

SIP IPv6
Game data

Chat IP Connection
Thomas
Peter
Peter: 00:00:00 Invite
Thomas: 00:00:00 player

> Peter: I am Chat

going to win
this time! Push to
>Thomas: Stream
Yeah right, in
your dreams!
Quit

116
Example of peer-to-peer IP connectivity
UMS CSCF
Peter chooses to
add a streaming
component to share
what he is seeing

SIP IPv6
Game data

Streami IP Connection
Thomas ng video Peter
Streaming video from
Peter: Peter:
00:00:00 Invite
Thomas: 00:00:00 player

> Peter: hey, Chat

look what
just passed Push to
by! Stream

Quit

117
 Future mobile services = serverless media
UMS CSCF

Peter: 00:00:00
Thomas: 00:00:00

SIP IPv6
Game data
Chat IP Connection
Thomas
Peter

No NATs in between, public IP addresses

are needed
The SIP/IMS user plane is peer-to-peer in
nature - SIP/IMS sessions between mobiles in Example services: gaming, chat,
different Private IPv4 address spaces become streaming, Voice/video over IP, etc.
highly complicated. This is why public IP
addresses are required. The only future proof
solution is provided by IPv6.

118
Standardized technology enablers for
new mobile services are here today
IPv6 Color
SIP
displays XHTML and
MMS
TCP/IP
Imaging
GPRS

Multimode
and camera
integration EDGE
WCDMA
CDMA2000
Video Bluetooth
WLAN
Multimedia
Streaming Positioning
Symbian MIDI
Java Presence
DRM

119
Technology and Application Trends

2G and 3G radio interfaces

2G radio
(WCDMA / CDMA2000)
interface
(GSM / EDGE) IPv4/IPv6 dual stack
IPv4 Peer-to-peer connectivity
Client-server
connectivity Richer, IP-based Applications
SMS text HTTP/TCP/IP browsing
Presence
messaging,
WAP browsing, Instant Messaging

MMS Multimedia streaming

multimedia Gaming

messaging Voice and video telephony

Sharing

Etc.

120
 Multi-access IMS

S-CSCF
IMS
P-CSCF (IPv6)
3GPP GGSN
access P-CSCF
nw P-CSCF

PDSN 3GPP2
access
WLAN nw
access nw
Common IP
version (=IPv6)
makes the multi- SIP
access case
much easier SIP Signaling for building up the session
User IP data

121
 References

Anders Kristensen, Hewlett-Packard

Laboratories, Bristol, U.K
Nicolas FISCHBACH, Senior Manager, IP
Engineering/Security - COLT Telecom
Jonathan Rosenberg, Dynamicsoft
Ed Luff, Newport Networks
Patrick Ferriter, ZULTYS

122