TAS general introduction

and SIP basics

Budapest
Laszlo Juhasz 05/05/2014
For internal use only
1 © Nokia Siemens Networks
 Agenda

• IMS network fundamentals

• SIP fundamentals
• SIP message details
• SIP architecture
• SIP Basic call setup
• Session Description Protocol (SDP)

For internal use only

2 © Nokia Siemens Networks
 How IMS works?
Session setup (IMS to IMS)
• So the basic IMS-IMS session setup involves the originating UE originating a session, the session traversing the
network, and the session terminating at the destination UE.
• Assuming special treatment is needed for the request, S-CSCF based on iFC invokes the Application Server(s)
hosting the services where the request is treated and after service execution it is returned to S-CSCF.

Home network of A Home network of B NSN TAS

HSS

AS1 AS2 AS1 AS2

Visited network of A Visited network of B

I-CSCF
S-CSCF P-CSCF
S-CSCF
P-CSCF
PS Network
PS Network

UE
eNb UE
4G/3G/2G I-CSCF
eNb
4G/3G/2G

For internal use only

3 © Nokia Siemens Networks
What is OpenTAS? O&M Lawful
SMSC Billing Prepaid Interception
• Voice Over IP based Application Server which provides
• Services for Voice, Video, Chat, File transfer
• Service Authorization
• Billing
• Call Interception
• Intelligent Services SIP MSS VoIP
Server
• High availability
• Geographical redundancy TAS

• SMS delivery over LTE 2G RAN

• Service Continuity Application which provides MGW
3G RAN
• Seamless service continuity between CS Voice and
LTE/Broadband
Voice Over LTE
• Handover support between 2G/3G and LTE
• Evolved from MSC Server by reusing the essential software components
• Upgragable from already existing MSC Server
• From T17 all the MSS only functionalties are removed

For internal use only

4 © Nokia Siemens Networks
Session Initiation Protocol

For internal use only

5 © Nokia Siemens Networks
 SIP fundamentals

For internal use only

6 © Nokia Siemens Networks
 History, IETF
• Internet Engineering Task Force
• Closely SIP related WGs: SIP, SIPPING, SIMPLE, MMUSIC, impp

• 1992: Multicast conferencing

• 1996: Earliest internet draft
• February 1999: IETF Proposed Standard
• March 1999: RFC 2543 (MMUSIC WG) - SIP version 2.0
• June 2002: RFC3261 (SIP WG), obsoletes old RFC – updated version 2.0
• SIP WG: core SIP protocol and SIP extensions
• SIPPING WG:
• the use of SIP for several applications related to telephony and multimedia
• develop requirements for any extensions to SIP needed for the applications

• MMUSIC WG: develop protocols to support Internet teleconferencing sessions (SDP, SAP)
• impp WG (Instant Messaging and Presence Protocol): common profile (protocol independent)
for presence and messaging -> SIP based solution in SIMPLE WG

For internal use only

7 © Nokia Siemens Networks
What is a “Session”?

A multimedia session is a set of multimedia senders and receivers

and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session
SIP is used to negotiate multimedia
Uses SIP Dialogs

For internal use only

8 © Nokia Siemens Networks
 SIP: Session Initiation Protocol
• Signaling protocol
• In order to support telephone-like services, signaling protocols are
needed to setup and describe sessions (calls)
• SIP is an end-to-end, application-layer signaling protocol, its main
purpose is to establish, modify and terminate sessions with one or more
participants:
• IP telephony calls, multimedia sessions
• Internet multimedia conferences

• Sessions are: audio, video, game, chat, …

• Media transport protocols: RTP, RTCP
• Part of IETF conference control architecture
(RSVP, RTP, RTSP, SAP, SDP)

For internal use only

9 © Nokia Siemens Networks
SIP key features..

“Lightweight”, application-layer signaling protocol

• Protocol primitives: session setup, modification, termination
Request/Response based (HTTP like) client-server protocol
• Clients send requests to servers and servers send responses
• A request invokes a method on the server
Note: however SIP look similar to HTTP, there are fundamental
differences like: transaction FSM, multi-hop signaling path, forking,
nodes acts both clients and servers
Textual protocol design
• Text based encoding
• Client  Server: method
• Server  Client: status code

For internal use only

10 © Nokia Siemens Networks
…SIP key features

Modular architecture: SIP is designed as part of the overall IETF

multimedia data and control architecture
• QoS, directory access, service discovery, session description,
conference control: separate protocols
• Protocols can easily be replaced
• Allows integration of multiple protocols, e.g. SDP, RTP, RTCP
• Any protocol can be used for session and media description (SDP is
the most common)
Separation of signaling and media (SIP concentrate on signaling)
Extensible
Web oriented: uses http syntax and URL “schemes” for integrating
other Internet resources
• SIP addresses may be embedded in web pages, e-mail signatures,
business cards
Transport protocol neutral
11
• can run over reliable (TCP, SCTP) and unreliable transport (UDP)
For internal use only
© Nokia Siemens Networks
SIP message details

For internal use only

12 © Nokia Siemens Networks
Request/response based

SIP Request User Agent

User Agent
SIP Response
Client Server
Network of
SIP Servers
End System End System
Caller Callee

For internal use only

13 © Nokia Siemens Networks
Terminology
Dialog
• peer-to-peer SIP relationship between a UAC and UAS that
persists for some time.
• established by SIP messages, such as a 2xx,1xx response to an
INVITE request.
• dialog-ID: call identifier, local tag, and remote tag
Subsequent Request: requests sent within the dialog
Target Refresh Request: subsequent request that can modify the target
of the dialog
Transaction
• between a client and a server: all messages from the first request
sent from the client to the server up to a final (non-1xx) response
sent from the server to the client
• also includes ACK for the response in the case the response was a
non-2xx
• ACK for a 2xx response is a separate transaction
”One-shot” request or Non-INVITE transactions
• does not create dialog, simple request-response interaction
(MESSAGE)
For internal use only
14 © Nokia Siemens Networks
 SIP methods (requests)
Base SIP methods (according to RFC 3261) are invoked on servers when
requests arrive:
• REGISTER requests conveys location information of users to Registrars,
makes binding between SIP AoR and Contact address
• An INVITE request invites a user to participate in a session or conference
– The message body usually contains a description of the session (SDP)
• ACK requests are used to confirm responses for INVITE, for reliable
message exchanges
• CANCEL requests cancel the pending request of the session
• BYE requests are used to terminate active sessions
– Any party of the session can send it
• OPTIONS requests are used to query information about servers'
capabilities
Extension methods e.g. INFO,MESSAGE,SUBSCRIBE,NOTIFY,REFER
• unknown methods are forwarded as regular transactions

For internal use only

15 © Nokia Siemens Networks
SIP responses

HTTP look-alike
Hierarchically organized three digit codes: status code - text
associated with the code
Provisional and final responses divided into 6 response classes:
• 1xx responses are informational messages e.g., 180 Ringing
• 2xx response shows a successful transaction e.g., 200 OK
• 3xx responses are redirect messages e.g., 301 Moved
Permanently
• 4xx responses indicate errors in requests e.g., 400 Bad Request
• 5xx responses indicate server errors e.g., 500 Version not
supported
• 6xx responses indicate global failures e.g., 600 Busy everywhere
For most codes, software only has to know the class of the status
code
For internal use only
16 © Nokia Siemens Networks
 SIP Addressing
SIP is about communication between users at hosts, identified by
SIP/SIPS URIs, which take the form sip:user@host[parameters]
[headers]
• user is a user name or a telephone number
• host is a domain name or numeric network address
• parameters define the specific parameters of URL: transport, time to live
• headers is another, rarely used form, to pass extra information
Examples of SIP URLs
• sip:[email protected]?subject=callme
• sip:[email protected];transport=tcp;user=phone
• sip:[email protected];method=MESSAGE
SIPS URI
• Secure URI, TLS is used end-to-end
Other schemes: tel, im, pres …

For internal use only

17 © Nokia Siemens Networks
SIP Addressing

Types of addresses
• AOR: Address of Record -> identifies a use
– e.g. sip:[email protected]
– Need DNS NAPTR/SRV record to resolve it
– Tutorial for DNS NAPTR/SRV:
http://anders.com/cms/264/SIP/DNS/NAPTR/SRV/dnscache/tinydns

• FQDN: Fully qualified domain names -> identifies a device

– e.g. sip:[email protected] or sip:[email protected]

For internal use only

18 © Nokia Siemens Networks
SIP message format

Start line contains the SIP version and

• the method and the address in
requests
• the status in responses Start-Line
Headers contain the information related Header1: value1
to the call in text lines: Header1: value2
Header3: value3
• e.g., the initiator, and the recipient of Header4: value4
the request, call identifier etc.
Message body (payload) can carry any
text based information Message body
• Usually it is a SDP message

For internal use only

19 © Nokia Siemens Networks
Example SIP message

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:[email protected]>;tag=9fxced76sl
To: Bob <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 151

v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

For internal use only

20 © Nokia Siemens Networks
Mandatory headers

From Dialog indentifier:

The combination of the To tag, From tag,
To and Call-ID completely defines a
peer-to-peer SIP relationship
Call-ID between Alice and Bob and is
referred to as a dialog.
CSeq
Transaction indentifier
Via

Contact

Max-Forwards

For internal use only

21 © Nokia Siemens Networks
Request-URI

INVITE sip:[email protected] SIP/2.0

It indicates the user or service to which this request is being

addressed
Typically when the UAC creates the request: Request-
URI=To
The UAC can set the Request-URI from the Contact header
field of a response to a previous request
The servers are able to change the Request-URI but not
the To, From, Contact

For internal use only

22 © Nokia Siemens Networks
To and From header fields
From: Alice <sip:[email protected]>;tag=9fxced76sl
To: Bob <sip:[email protected]>

Common headers
To: It specifies the logical call destination, (usually AoRs), It has no use in SIP,
target is defined by RURI
From: It specifies the logical call source, (usually AoRs)
This headers must be present in all SIP messages
The value of these fields in responses are copied from the request

UA1 UA2
INVITE
From: Name1 <sip: [email protected]>
To: Name2 <sip:[email protected]>;user= phone
200 OK
From: Name1 <sip: [email protected]>
To: Name2 <sip:[email protected]>;user= phone

For internal use only

23 © Nokia Siemens Networks
 The Via concept
Via: SIP/2.0/TCP
client.atlanta.example.com:5060;branch=z9hG4bK74bf9
In requests the terminal and the proxies put a new Via header with their name in the SIP
message
In responses the proxies delete their names from the top most Via field
• If it is not there the message is discarded
It is used to ensure that responses take the same path as request and for loop detection
(response routing)
The Via must contain a globally unique branch parameter (starting with z9hG4bK). (server
transaction optimisation)

Proxy
UA1 UA2
INVITE INVITE
Via: SIP/2.0/UDP host.com:5060; Via: SIP/2.0/UDP proxy.com:5060; branch=
branch= Via: SIP/2.0/UDP host.com:5060; branch=
200 OK
Via: SIP/2.0/UDP proxy.com:5060; branch=
200 OK
Via: SIP/2.0/UDP host.com:5060; branch=
Via: SIP/2.0/UDP host.com:5060;
branch=

For internal use only

24 © Nokia Siemens Networks
Call-ID and CSeq header fields

Call-ID: [email protected]
CSeq: 1 INVITE

Call-ID: It uniquely identifies a particular dialog or registration

CSeq: It is a decimal number and a method that uniquely identifies the transaction
in a dialog
This headers must be present in all SIP messages.
Endpoint maintain separate CSeq numbering space

UA1 UA2
INVITE Call-ID: 123@UA1host CSeq: 1 INVITE
200 OK Call-ID: 123@UA1host CSeq: 1 INVITE
ACK Call-ID: 123@UA1host CSeq: 1 ACK

INVITE Call-ID: 123@UA1host CSeq: 2 INVITE

200 OK Call-ID: 123@UA1host CSeq: 2 INVITE
ACK Call-ID: 123@UA1host CSeq: 2 ACK
For internal use only
25 © Nokia Siemens Networks
 Contact Header

Contact: <sip:[email protected];transport=tcp>
Contact indicates location of redirection
• used in INVITE, ACK and REGISTER requests and 1xx, 2xx, 3xx and 485 (Ambiguous)
responses
• indicates addresses where user can be located; allows bypassing proxies
Can be any suitable location where caller can be reached: not limited to SIP URLs
• e.g., phone, pager, mailto, http, ...
Fields
• q location preference
• service service provided by terminal: IP, PSTN, pager, ...
• media media supported by terminal: audio, video, ...
• description display to caller
• class business, residence
• expires expiration time
• features other features of this address
• language languages spoken by answering party
• priority “only in case of emergency”

For internal use only

26 © Nokia Siemens Networks
Contact Example

SIP/2.0 301 Moved temporarily

Contact: sip: [email protected]
– ; service=IP, voice-mail
– ; media = audio ; duplex=full ; q=0.7
Contact: sip:[email protected]; user=phone; service=PSTN
– ; mobility=fixed ; language=en ; q=0.5
Contact: phone: +36-50-234-5678; service=pager
– ; mobility=mobile ; duplex=send-only ; media=text
– ; description=“For emergencies only” ; q=0.1
Contact: mailto: [email protected]

For internal use only

27 © Nokia Siemens Networks
Max-Forwards header

Max-Forwards: 70

Mandatory header
Max-Forwards value is decremented by every proxy
If reaches 0 the request is responded with a 483 Too Many Hops
responses.
Used for loop detection

For internal use only

28 © Nokia Siemens Networks
 Content-Type and Content-Length header fields

Content-Type: application/sdp
Content-Length: 151
Content-Type: It describes the media type of the message
body
Content-Length: The number of octets in the message body
• It is mandatory in SIP messages sent over stream based
protocols (e.g. TCP)

For internal use only

29 © Nokia Siemens Networks
Record-Route/Route headers
SIP proxies may decide to remain on the SIP signaling path to see all the messaging
between the endpoints for the duration of the session
Proxy inserts its own URI to the Record-Route header
UAS copies all Record-Route header values from the request into the response
When UAC prepares subsequent requests, it copies the list of URIs from the Record-
Route header to the Route header

UA1 Proxy1 Proxy2 UA2

INVITE INVITE
INVITE Record-Route: <proxy1> Record-Route: <proxy1>

183 183
183 Record-Route: <proxy1>
Record-Route: <proxy1> Record-Route: <proxy1>
Prack
Route: <proxy1> Prack

200 OK (to Prack) 200 OK (to Prack)

200 OK (to INVITE)
200 OK (to INVITE)
200 OK (to INVITE)
For internal use only
30 © Nokia Siemens Networks
Extensibility and Feature Negotiation
Receivers ignore headers, parameters they don’t understand
Supported features can be specified in request and response
• Supported UAC and UAS tell features they support
Required features can be specified in request and response
• Require UAC tells UAS about required options
• Proxy-Require required options for proxy/redirect servers
• Many extensions use Require and Proxy-Require to specify their support
• 420 Bad Extension can indicate that the required extension is not
supported
• 421 Extension Required can indicate that a specific extension is required
Allow header specifies which methods are supported. This is about which
can be received.
New methods can be added without changing the protocol
• server can respond with 405 Method Not Allowed
• returns list of supported methods in Allow header
• client can ask which methods are supported using OPTIONS
For internal use only
31 © Nokia Siemens Networks
SIP architecture

For internal use only

32 © Nokia Siemens Networks
SIP elements

User-agents (UAC+UAS), terminals

SIP Servers
• Proxy
• Redirect
• Registrar
• Location Server
• B2BUA: Back-to-back User Agent
– concatenation of a UAC and UAS
– it has no explicit definition in RFC 3261

For internal use only

33 © Nokia Siemens Networks
SIP Terminal

SIP User Agent (UA) or Terminal is the endpoint of sessions

• It sends and receives session initiation requests
• It is the endpoint of multimedia streams
• Usually it is an application in a computer, but it can be a dedicated
hardware appliance
It consists of two parts:
• User Agent Client: initiate calls, caller application
• User Agent Server: accept, redirect, reject call, sends responses
for incoming requests on behalf of the user
Gateways are special cases of user agents

For internal use only

34 © Nokia Siemens Networks
SIP Network Elements

SIP messages may pass through several SIP servers

These Servers are used to route and redirect requests
Proxy servers: server+client, receives and forwards SIP requests
• It can interpret or rewrite SIP messages
• Forking proxy: A proxy server can also send a request to a
number of locations at the same time
– Paralell/Sequential forking
Redirect servers map the address of requests into new addresses
• redirect requests, does not participate in the transaction
Location Servers keep track of the location of users
Registrars are servers that accepts REGISTER requests
• These servers are typically co-located with each other in one
physical network element
For internal use only
35 © Nokia Siemens Networks
Stateful vs. stateless
Note: it’s very often a basis for misunderstanding what
do we call stateful
Call stateful/Dialog stateful
• A proxy is call stateful if it retains state for a dialog
from the initiating INVITE to the terminating BYE
request
Transaction stateful
• A proxy that maintains the client and server
transaction state machines during the processing of a
request

Stateless
• A proxy that forwards every request it receives
downstream and every response it receives upstream
• No states are maintained
For internal use only
36 © Nokia Siemens Networks
SIP Registration

home.com

Location
server

2. [email protected]
at 172.22.21.22
example.hu 1. REGISTER sip:home.com
From: <sip:[email protected]>
To: <sip:[email protected]>
Contact: <sip:172.22.21.22>
Expires:3600

SIP

3. 200 OK

Registrar

For internal use only

37 © Nokia Siemens Networks
SIP Operation in Proxy Mode

home.com

Location
server
SIP

Ws-sbdy

2. somebody
example.hu

3. 172.22.21.23
[email protected] 1. INVITE
[email protected] 4. INVITE
172.22.21.23
SIP

6. 200 OK
5. 200 OK
8. ACK
7. ACK
172.22.21.23
[email protected]

For internal use only

38 © Nokia Siemens Networks
SIP Operation in Redirect Mode

example.hu 2. somebody
1. INVITE
[email protected] [email protected]
3. etsi.org
Location
SIP
4. 302 Moved temporarily server
Contact: [email protected]

5. ACK home.com
[email protected]
etsi.org
6. INVITE [email protected]

7. 200 OK SIP

8. ACK [email protected]

For internal use only

39 © Nokia Siemens Networks
SIP “Trapezoid”

DNS Server Location

Server

DNS

SIP
Outbound Inbound Proxy
Proxy Server Server

SIP
SIP

SIP

Media (RTP)

User Agent A User Agent B

For internal use only

40 © Nokia Siemens Networks
Basic SIP call setup

For internal use only

41 © Nokia Siemens Networks
Transport for SIP

SIP is independent of the low-layer transport, designed for IP networks ,

to be used on top of UDP/TCP/SCTP
SIP transport layer is responsible for the actual transmission of the
requests and responses
Filling Via sent-by
Framing (TCP Content-Length handling, UDP truncation)
Applying the size rule
• UDP preferred for messages < ~1300 bytes
• TCP must be used over path-MTU-200 or ~1300 bytes
Error handling (fallback)
Managing connections in case of stream oriented transport

For internal use only

42 © Nokia Siemens Networks
TCP as transport

For INVITE request there is always an outgoing and an incoming

TCP connection
• Outgoing is created by the UAC when the INVITE is sent out.
Responses are sent on this connection
• Incoming is created when the UAS wants to send a request inside
the dialog (e.g BYE)
Connection can be reused later and not connected only to one
session
Fallback is executed when the connection setup fails, but in case of
congestion error there is no fallback

For internal use only

43 © Nokia Siemens Networks
SIP Transactions, cont.

Transaction clients and servers:

UAC INVITE Proxy Stateless Proxy UAS
T T
INVITE
r r
100 Trying INVITE
T T
180
r S C r
e l 180

C r i S
l 180 v e 200 Ok e
i e n 200 Ok r
e r t v
n 200 Ok e
t r
ACK

BYE

200 Ok

Special cases for ACK:

• ACK to 2xx responses is a separate transaction
• ACK to 3xx .. 6xx is included in the INVITE transaction
For internal use only
44 © Nokia Siemens Networks
SDP Offer/Answer in SIP, Introduced by RFC 3261
UAC UAS

INVITE (Offer SDP1)

UAC UAS
180 Ringing (Answer SDP 2)

INVITE (Offer SDP1)

200OK (Answer SDP 2)

ACK

180 Ringing

200OK (Answer SDP 2)

ACK
UAC UAS

reINVITE (Offer SDP3) INVITE (no SDP)

200 OK (Answer SDP 4)

ACK

180 Ringing

200OK (Offer SDP 1)

ACK (Answer SDP 2)

For internal use only

45 © Nokia Siemens Networks
SDP Offer/Answer in SIP, Introduced by RFC 3262

UAC UAS UAC UASUAC UAS

INVITE (Offer SDP1) INVITE (Offer SDP1)

INVITE (no SDP)

180 Ringing (Answer SDP 2) 180 Ringing (Answer SDP 2)

180 Ringing (Offer SDP 1)
PRACK (Offer SDP 3) PRACK
PRACK (Answer SDP 2)
200OK (Answer SDP 4) 200OK
200OK

200OK 200OK
200OK
ACK ACK
ACK

Note:
- PRACK does not require these sequences
- Simple RFC3261 exchanges still apply

For internal use only

46 © Nokia Siemens Networks
The UPDATE method (RFC 3311)

UPDATE allows a client to

update parameters of a sessionUA1 UA2
INVITE (offer 1)
• set of media streams and
their codecs 183 Session Progress (answer 1)
UPDATE is a target refresh PRACK
request so it has impact on the
state of a dialog, but only the 200 OK (PRACK)
Contact can be changed UPDATE (offer 2)
UPDATE can be sent before the
initial INVITE has been completed 200 OK (answer 2) (UPDATE)

• Useful for updating session 200 OK (INVITE)

parameters within early dialogs
ACK

For internal use only

47 © Nokia Siemens Networks
SDP Offer/Answer in SIP, Introduced by RFC 3311

UAC UAS

INVITE (Offer SDP1)

180 Ringing (Answer SDP 2)

PRACK (Offer SDP 3)

200OK (Answer SDP 4)

UPDATE (SDP Offer 5)

200OK (Answer SDP6)

UPDATE (SDP Offer 7)

200OK (Answer SDP8)

200OK
ACK

UPDATE (SDP Offer 9)

200OK (Answer SDP10)

For internal use only

48 © Nokia Siemens Networks
 Instant Messaging

For internal use only

49 © Nokia Siemens Networks
Instant Messaging

Paging (One-shot messaging)

• Like SMS, but no storing
• I'm sending a single message, may not expect
immediate response
• No conversation, no interaction expected
• => SIP MESSAGE

For internal use only

50 © Nokia Siemens Networks
Paging Mode Instant Messaging
(RFC 3428)
MESSAGE method
• carries the instant message content in the request body
• body can be MIME body type, “text/plain”, “message/cpim”
MESSAGE requests do not initiate a SIP dialog, each Instant Message stands
alone
MESSAGE requests may be sent in the context of a dialog

GuyA Proxy GuyB

[email protected] [email protected]

MESSAGE MESSAGE
200 OK 200 OK

For internal use only

51 © Nokia Siemens Networks
Paging in Action

Case 1: small messages

SIP: MESSAGE / 200

For internal use only

52 © Nokia Siemens Networks
 SIP Instant Message Scenario
1. A sends an Instant Message to B
DNS Server Location saying “Can you talk now?” in a
Server MESSAGE request.
2., 3. & 4. MESSAGE request is proxied,
Location Server queried.
3. LS Query: B? 4. Response: 5. Inbound Proxy forwards MESSAGE to B.
sip:[email protected] 6. User Agent B responds with 200 OK.
7. & 8. 200 OK is proxied back to A.
2. MESSAGE
<Can you
talk now?> Inbound Proxy
Outbound
Proxy Server Server

7. 200 OK
1. MESSAGE
<Can you 5. MESSAGE
talk now?> 8. 200 OK <Can you
talk now?> 6. 200 OK

User Agent A User Agent B

For internal use only

53 © Nokia Siemens Networks
 SIP Instant Message Scenario
1. B sends an Instant Message to A
Location DNS Server saying “Sure.” in a MESSAGE sent to
Server A’s AOR URI.
2. & 3. DNS Server is queried.
4. Outbound Proxy forwards MESSAGE to
5. LS Query: A? 6. Response: sip:[email protected] 2. DNS Query: 3. Response: 5.6.7.8 Inbound Server.
mci.com?
5. & 6. Location Server is queried.
7. Inbound Proxy forwards to A.
4. MESSAGE 8. User Agent A responds with 200 OK.
<Sure.> Outbound 9. & 10. 200 OK is proxied back to B.
Inbound Proxy
Server Proxy Server

9. 200 OK
7. MESSAGE
<Sure.> 8. 200 OK
1. MESSAGE 10. 200 OK
<Sure.>

User Agent A User Agent B

For internal use only

54 © Nokia Siemens Networks
 Session Description Protocol (SDP)

For internal use only

55 © Nokia Siemens Networks
Session Description Protocol

SDP is intended to describe multimedia sessions

It is a text based protocol
Caller and callee indicate receive capabilities, media formats and
receive address/port

For internal use only

56 © Nokia Siemens Networks
Capability Exchange

Can be performed
• In the Session setup
• During the Session

For internal use only

57 © Nokia Siemens Networks
SDP Message Contents

Session level description

– session identifier
– other session-level parameters, such as IP address
– Subject
– Contact info about the session and/or creator
Timing Description
– Start and stop times
– Repeat times
One or more media level descriptions
– media type and format
– transport protocol and port number
– other media-level parameters

Must appear in that order

Media address may not be the same as signalling address

For internal use only

58 © Nokia Siemens Networks
Session Description

Field Description Mandate

v Protocol version m
o Origin and session ID m
s Session Name m
i Session information o m = mandatory
u URI for session o
o = optional
e Email address o
p Phone number o
c Connection information m*
b Bandwidth information m
z Time zone correction o
k Encryption key o
a Attribute lines o * Not required if present for every media line

For internal use only

59 © Nokia Siemens Networks
Time Description

Field Description Mandate

t Time session is active m
r Repeat times o

For internal use only

60 © Nokia Siemens Networks
Media Description

Field Description Mandate

m Media and transport o
i Media title o
c Connection information o*
b Bandwidth information o
k Encryption key o
a Media attributes o

* Not required if present at session level

For internal use only

61 © Nokia Siemens Networks
SDP Message Format

<character>=<value>
• There are no spaces allowed on either side of the ‘=’
sign.
Value= parameter1 parameter2 … parameterN
• There is exactly one space between each parameter

Each line ends with CRLF

Each line has a defined number of parameters

For internal use only

62 © Nokia Siemens Networks
Protocol Version Line

Always set to 0
v=0

For internal use only

63 © Nokia Siemens Networks
Connection Information Line

Must be present at session level or media level

Must be present at media level if not present at session
level
c=<network type> <address type> <network address>
• Network type: IN (Internet)
• Address type: IP4 or IP6
• Network address: IP address or domain name

For internal use only

64 © Nokia Siemens Networks
Origin

• o=<username> <session id> <version> <network type>

<address type> <address> The "o=" field gives the
originator of the session (their username and the
address of the user's host) plus a session id and session
version number.

For internal use only

65 © Nokia Siemens Networks
Media Line

m line carries information about the media

m=<media> <port> <transport> <format-list>
• Media: is the type of media. Eg: audio, video, game, poc
• Port: contains the port number where this media can be received
– If transport is RTP, port number for RTCP = RTP port + 1
– RTP port number must always be an even number
• Transport: the transport protocol to use (UDP or RTP/AVP*)
• Format-list: contains more information about the media. Usually contains
payload types defined in RTP Audio/Video profiles* that should reference a
MIME subtype for the media

• * See RTP section of the presentation

For internal use only

66 © Nokia Siemens Networks
Attribute Line

Defines attributes of the media

This is the only way to extend SDP
a=<attribute field> [“:”<attribute value>]

For internal use only

67 © Nokia Siemens Networks
Attribute Line examples

a=sendrecv (default if not present)

a=sendonly
a=recvonly
a=inactive
a=rtpmap:0 PCMU/8000
a=framerate: 15 (for video only)

For internal use only

68 © Nokia Siemens Networks
SDP Example

v=0
o=bob 289084526 28904529 IN IP4 labpc1.nokia.com
s=-
c=IN IP4 123.123.14.2
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly

For internal use only

69 © Nokia Siemens Networks
RTP and RTCP

• RTP is a data transfer protocol, which deals with the transfer of

real-time data.

• RTP carries the media streams

• RTCP is a control protocol. It is used to specify quality of service

(QoS) feedback and synchronization between the media streams.

• RTP and RTCP packets are typically sent over UDP

For internal use only

70 © Nokia Siemens Networks
 Offer/Answer Model

For internal use only

71 © Nokia Siemens Networks
Offer/Answer 1

The offer/answer model (RFC3264) defines how to use SDP for

codec negotiation and bearer information exchange)
Basic rules:
• SDP answer must be sent in reliable non-failure responses (18x
without PRACK is unreliable), but the same exact answer can also
be sent in any provisional response
• No new offer can be sent until the previous offer is answered or
rejected
• No SDP offer can be sent until the received SDP offer is answered
• Media streams can be rejected by setting the port to zero but the
media line cannot be deleted (not even from subsequent
offer/answers)

For internal use only

72 © Nokia Siemens Networks
Offer/Answer 2

Offer/Answer (O/A) model defines way for two endpoints to reach a

common view of a multimedia session
• Own RFC (3264)
• Useful in unicast sessions where negotiation between two parties
is necessary, ie normal SIP calls and back-to-back UA:s
• Also defines how to update an existing session
Basic offer rules
• Offerer must be ready to receive media
• First codec is the preferred codec
Basic answer rules
• Codecs are in the same order and with the same payload type
• Each media line exist, answerer can add extra lines
• Declined media line must have at least one codec listed
• Direction-attributes are reversed
For internal use only
73 © Nokia Siemens Networks
Offer/Answer example
Offer: Answer:
v=0
o=jari 2890844526 2890844526 IN IP4 hews001.nokia.com v=0
s= o=- 2890844730 2890844730 IN IP4 gw.nokia.com
c=IN IP4 172.21.41.115 s=
t=0 0 c=IN IP4 172.21.41.1
m=audio 49170 RTP/AVP 0 96 97 t=0 0
a=rtpmap:0 PCMU/8000 m=audio 65422 RTP/AVP 0 96 97
a=rtpmap:96 X-AMR/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:97 X-AMR-WB/16000 a=rtpmap:96 X-AMR/8000
m=audio 51434 RTP/AVP 110 a=rtpmap:97 X-AMR-WB/16000
a=rtpmap:110 telephone-events/8000
a=recvonly m=audio 53354 RTP/AVP 110
m=video 51372 RTP/AVP 31 a=rtpmap:110 telephone-events/8000
a=rtpmap:31 H261/90000 a=sendonly
m=video 53000 RTP/AVP 32 m=video 0 RTP/AVP 31
a=rtpmap:32 MPV/90000 m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

• Things to note in the answer above:

• Codecs are in the same order and with the same payload type
• All media lines exist (declined media is marked by port number 0)
• Declined media line must have at least one codec listed
• Telephone events direction-attribute is reversed

For internal use only

74 © Nokia Siemens Networks
Offer

Caller in the session generates an SDP that constitutes

the offer
• The set of media streams the offerer wishes to use
• The set of codecs the offerer wishes to use
• The IP addresses and ports the offer would like to use
to receive the media

For internal use only

75 © Nokia Siemens Networks
Answer

The answerer generates an answer, which is an SDP

that responds to offer provided it.
The answer indicates:
• whether a stream is accepted or not
• the codecs that will be used (subset of the offer)
• the IP addresses and ports that the answerer wants to
use to receive media

For internal use only

76 © Nokia Siemens Networks
Offer/Answer restrictions

The client MUST NOT generate a new offer if it has received an offer which it
has not yet answered or rejected

UA 1 UA 2
offer

offer

For internal use only

77 © Nokia Siemens Networks
Offer/Answer restrictions

The client MUST NOT generate a new offer if it has

generated a prior offer for which it has not yet received an
answer or a rejection

UA 1 UA 2
offer

offer

For internal use only

78 © Nokia Siemens Networks
Offer/Answer restrictions

If multiple media streams of different types are present, it

means that the offerer wishes to use those streams at the
same time

UA 1 UA 2

Offer
m=audio 49170 RTP/AVP 0 8 97
m=Video 49172 RTP/AVP 31 32

For internal use only

79 © Nokia Siemens Networks
Offer/Answer restrictions

Number of m-lines in an answer must equal that of the

offer

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 97 m=audio 49170 RTP/AVP 0 8 97
m=Video 49172 RTP/AVP 31 32 m=Video 49172 RTP/AVP 31 32

Answer Answer
m=audio 55220 RTP/AVP 0 8 97 m=audio 55220 RTP/AVP 0 8 97
m=Video 55222 RTP/AVP 31 32

For internal use only

80 © Nokia Siemens Networks
Offer/Answer restrictions

Rejecting a media is done by setting the port in a media

line to 0

UA 1 UA 2

Offer
m=audio 49170 RTP/AVP 0 8 97
m=Video 49172 RTP/AVP 31 32

Answer
m=audio 55220 RTP/AVP 0 8 97
m=Video 0 RTP/AVP

For internal use only

81 © Nokia Siemens Networks
Offer/Answer restrictions

If multiple media streams of the same type are present in

an offer, it means that the offerer wishes to send (and/or
receive) multiple streams of that type at the same time
• Each stream may use different encoding

UA 1 UA 2

Offer
m=audio 49170 RTP/AVP 0
m=audio 49172 RTP/AVP 8

For internal use only

82 © Nokia Siemens Networks
Offer/Answer restrictions

When the offer receives the answer, it MUST send using a

media format listed in the answer, and it SHOULD use the
first media format listed in the answer when it does send
UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP 31 32 m=Video 49172 RTP/AVP 31 32

Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP 31 32 m=Video 55222 RTP/AVP 31 32

Audio format 0 Audio format 97

For internal use only

83 © Nokia Siemens Networks
Modifying a Session Description
At any point during the session, either participant MAY issue a new offer to modify characteristics of
the session
The new SDP MUST have a matching media stream for each media stream in the previous SDP. In
other words, if the previous SDP had N "m=" lines, the new SDP MUST have at least N "m=" lines.

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP 31 32 m=Video 49172 RTP/AVP 31 32
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP 31 32 m=Video 55222 RTP/AVP 31 32
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP 31 32

For internal use only

84 © Nokia Siemens Networks
Modifying a Session Description

The i-th media stream in the previous SDP, counting from the top, matches
the i-th media stream in the new SDP, counting from the top.

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP 31 32 m=Video 49172 RTP/AVP 31 32
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP 31 32 m=Video 55222 RTP/AVP 31 32
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=Video 49172 RTP/AVP 31 32
m=Video 49172 RTP/AVP 31 32 m=audio 49170 RTP/AVP 0 8

For internal use only

85 © Nokia Siemens Networks
Modifying a Session Description

Because of the last 2 requirements, the number of "m="

lines in a stream never decreases, but either stays the
same or increases

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP 31 32 m=Video 49172 RTP/AVP 31 32
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP 31 32 m=Video 55222 RTP/AVP 31 32
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=Video 49172 RTP/AVP 31 32
m=Video 49172 RTP/AVP 31 32
m=game 49172 udp text

For internal use only

86 © Nokia Siemens Networks
Modifying a Session Description

Removing a media stream is done as before: by setting

the port value to 0

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP m=Video 49172 RTP/AVP 31 32
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP m=Video 55222 RTP/AVP 31 32
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 0 RTP/AVP

For internal use only

87 © Nokia Siemens Networks
Modifying a Session Description

New media streams added can reuse a media line that

was earlier disabled with a port 0

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 0 RTP/AVP m=Video 0 RTP/AVP
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 0 RTP/AVP m=Video 0 RTP/AVP
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 0 RTP/AVP m=game 49172 udp text
m=game 49172 udp text

For internal use only

88 © Nokia Siemens Networks
Putting Media Stream on Hold

If the stream to be placed on hold was previously a sendrecv media stream, it

is placed on hold by marking it as sendonly
If the stream to be placed on hold was previously a recvonly media stream, it
is placed on hold by marking it inactive

UA 1 UA 2 UA 1 UA 2

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP a=recvonly
Answer Answer
m=audio 55220 RTP/AVP 0 8 m=audio 55220 RTP/AVP 0 8
m=Video 55222 RTP/AVP a=sendonly
Audio format 0 Audio format 0

Offer Offer
m=audio 49170 RTP/AVP 0 8 m=audio 49170 RTP/AVP 0 8
m=Video 49172 RTP/AVP a=inactive
a=sendonly m=Video 49172 RTP/AVP
a=sendonly

For internal use only

89 © Nokia Siemens Networks
 Offer
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=-
c=IN IP4 pc1.nokia.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 Supported audio codecs
a=rtpmap:97 iLBC
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
Supported video codecs

For internal use only For internal use only

90 90© Nokia©Siemens Networks
Nokia Siemens Networks
 Answer
v=0
o=bob 2808844564 2808844564 IN IP4 host.there.com
s=-
c=IN IP4 host.there.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000  choice
m=video 49170 RTP/AVP 32
a=rtpmap:32 MPV/90000  choice

For internal use only For internal use only

91 91© Nokia©Siemens Networks
Nokia Siemens Networks
SIP Call Flow Scenarios
• Call Attempt - Unsuccessful
• Registration
• Call Setup – Successful

For internal use only

92 © Nokia Siemens Networks
 Thank You!

For internal use only

93 © Nokia Siemens Networks