SIP

Anna Sfairopoulou Page 1

SIP


What we will see...

• Signalling vs Media • SIP standarization and design principles• Message syntax• SIP addressing• SIP methods

– Request messages– Response messages

• SIP entities (servers)• Examples


Why SIP

• SIP VoIP + WLAN competition to cellular telephony?

• IMS component• P2PSIP• Application layer mobility using SIP


The si

mplest voice call

10.0.0.1192.168.20.2

Listening on port 5060Expecting UDPExpecting CODEC PCM A-law

Knows port 5060Knows UDPKnows CODEC PCM A-law

Knows address 192.168.20.2

Internet

Alice

Bob

Self-written C code:•Open socket•Take voice samples from microphone•Send voice samples in UDP packets

Self-written Java code:•Open socket•Wait for UDP packets•Playback voice samples


What if...

• Alice doesn't know Bob's IP address?• Alice uses a different codec?• Bob is busy in a previous call?• Bob is absent?• Other media desired (e.g. Video)?• Cesar would like to join in?

Some form of call control (a.k.a. SIGNALING) is needed!


Think about the road system...


Media vs Signaling

• To interchange user data, transport protocols are used– UDP– TCP

• To control that interchange, signaling protocols are used– RSVP– SIP– RTSP

(+ RTP on top)


Signaling serves to...

• Set up and tear down VoIP calls/sessions• Reserve bandwidth among routers• Establish secure connections over the

Internet• Interchange routing information• Inform of network malfunctions• Configure network equipment remotely• Etc.


The

ATM cube revisited


Layers vs Planes

• Layering: Structures how data transport is done in a network

• Planes: Define what purpose a data transfer serves:– User plane: Transfer of user info– Control plane: Control the transfer of user info– Management plane: Check and update status of

network elements (routers, servers, etc.)


The purpose of signaling

• Interchange of control information for the management of traffic aggregates and of the network as a whole

• Signaling protocols represent a parallel network for the purpose of network and traffic control

The complexity and the intelligence of the network lies mainly here!


The real “si

mplest” voice call


The real “si

mplest” voice call

SIP Express

Server (SER)

Database (MySQL)

DNS (Named)

Twinkle


Signalling

• Signalling serves to control user data transfer across the network– Data transfer is easy, signaling is hard!

• SIP is a session-layer signaling protocol• RTP is a session-layer data transfer protocol• UDP is the transport protocol mostly used to

transport both


SIP standardization

• First designed by Henning Schulzrinne and Mark Handley starting in 1996

• Standardized in IETF RFC 3261– See also RFC 3551, 2327, 3219, 3761, 3525,

3398 ...

• Decentralized design– The intelligence lies on the nodes

• Ongoing process– Extensions– Services


SIP design principles (I)

• Modelled after HTTP– Text-based

• Based on transactions– Request / response

• Simple– Less than 10 methods / packet types

• Only for call control– No QoS, no media transfer, no application-specific

functions


SIP design principles (II)

• Session-oriented– Can manage any session-based service

• Online gaming• Videoconferencing• Virtual reality• Chat• Etc


The SIP-related protocol “Zoo”

• Loosely coupled to other Internet protocols– SDP, DNS, SMTP, HTTP, RSVP, ...

• Defines complementary protocols to enable special services– TRIP, ENUM, SPIRITS, PINT, ...

• Any VoIP network needs a combination of protocols to work


VoIP protocol stack

SIP

TCP / UDP / SCTP?

MPEG, H.261, etc.

RTP

UDP

IP

RTCP, TRIP, etc.

TCP / UDP?

Fast/GigEth, ATM, 802.11 MAC/LLC, etc.

DSL, Phy GigEth,802.11 PHY etc.

Signaling Media Transport Support

Physical

Network

Transport

Session

Presentation

Layer

Datalink


SIP fundamentals

• Which messages do we need to control a VoIP call?– Let's try to find out...


A basic SIP call Alice Bob | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | |

INVITE sip:[email protected] SIP/2.0From: Alice <sip:[email protected]>To: Bob <sip:[email protected]>m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000

SIP/2.0 200 OKm=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000


Message syntax (I)

• SIP is request / response• Every request carries a method indicating

the request typeINVITE sip:[email protected] SIP/2.0

• Every response carries a status code explaining the answer

SIP/2.0 200 OK

Request Line

or

Status Line

Message

HeadersPayload


Message syntax (II)

• Both carry message headers with the parameters– Variable depending on method / context– Additional information about the message– Ex: From: Alice <sip:[email protected]>

• Payload transports additional info (normally using SDP)– No user data!– description of audio / video capabilities– Ex: m=audio 3456 RTP/AVP 0


SIP addressing

• SIP URL (Uniform Resource Locator)– Specify the location of a resource (user)– Email-like addresses– sip:User@Domain– But it is not an e-mail address!

• sip:[email protected]• sip:[email protected]

• Non sip URLs can be also found in SIP messages– mailto, tel. im …


Original SIP methods (I)

• Six methods defined initially in the standard– INVITE – ACK– BYE– CANCEL– OPTIONS– REGISTER


Original SIP methods (II)

• INVITE initiates sessions– session description included in message body– re-INVITEs used to change session state

• ACK confirms session establishment– can only be used with INVITE

• BYE terminates sessions


Original SIP methods (III)

• CANCEL cancels a pending INVITE

• OPTIONS capability inquiry

• REGISTER binds a permanent address to current location– may convey user data (CPL scripts)


SIP methods extensions

• INFO mid-call signaling• COMET preconditions met• PRACK provisional reliable responses ACK• SUBSCRIBE/NOTIFY/MESSAGE instant messaging• REFER call re-direction• UPDATE update call state• PUBLISH user info


SIP responses (I)

• Borrowed from HTTP: xyz code + explanatory text

• Receivers need to understand x• 1yz Informational

– 100 Trying– 180 Ringing– 183 Session in progress

• 2yz Success– 200 ok


SIP responses (II)

• 3yz Redirection– 300 Multiple choices– 302 Moved temporarily– 305 Use proxy

• 4yz Request failure– 400 Bad Request– 401 Unauthorized– 407 Proxy authentication required– 486 Busy Here


SIP responses (III)

• 5yz Server failure– 500 Server internal error– 501 Not implemented– 503 Service unavailable

• 6yz Global failure– 600 Busy everywhere– 606 Not acceptable


A basic SIP call (again) Alice Bob | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | |

INVITE sip:[email protected] SIP/2.0From: Alice <sip:[email protected]>To: Bob <sip:[email protected]>m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000

SIP/2.0 200 OKm=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000


SIP message headers

• Huge number of different headers– See RFC 3261– Nomenclature: SIP header = Other protocol's

header field

• Headers parameterize the request or response

• A SIP entity ignores headers it does not understand– Simplifies interworking


Header types

• General headers– Basic info to process the transaction– E.g. “To”, “From” and “Call-ID” headers

• Request headers– Additional info about request or sender– E.g. The “Subject” header

• Response headers– Additional info about response or receiver– E.g. “Unsupported” and “Retry-After” header

• Entity headers


A complete SIP message


Example: Invite message

Starting Line

Headers

Separator

Message Body


SIP entities: UAC & UAS

• User Agent Client (UAC)– Places calls– Sends requests

• User Agent Server (UAS)– Waits for incoming calls– Sends responses

• A SIP terminal is a UAC + UAS– Beware of this special client/server terminology!


SIP network entities

• Servers (UAS)– Proxy server– redirect server– registrar

• Can be combined in a single device p.e. SER!!!

• They deal only with signaling• Media is transported end-to-end

– There are exceptions...

Signaling controls media interchange: It is not necessary to touch the media streams directly!


SIP entities: Registrar

• Users register their contact info– Keeps the info at a Location Server

• (Which is simply a database)

– SIP address, but also other addresses, with a type indication:

sip:[email protected]:[email protected], user = phone

– Enables personal and terminal mobility and user behaviour patterns


Registration example


Registration example

• Contact could also be a specific locatione.x. pc1.grup2.labtel2.upf.edu

• Un-Register– Send the same message but with

EXPIRE = 0


SIP entities: Proxy server

• Proxy Server– Acts on behalf of UAC

• Processing the request• Responding to requests• Forwarding requests

– Can impersonate the client– Acts both as client and server– Forking proxies

• Forwards an INVITE to several destinations in parallel


Proxy example


Stateless vs Stateful proxy

• In general– Stateless: get a request, forward it, forget about

it– Stateful: remembers previous responses/requests

of a particular transaction act more intelligently on subsequent requests!

• Record-Route: force future messages to pass from this proxy


SIP entites: Redirect server

• Maps destination SIP addresses to “reachable” addresses– SIP address, e-mail, telephone number,

etc.– Depending on user preferences

• Informs the client about them– No message forwarding!


Redirection example


Additional examples(taken from RFC 3665 and Collins)


Session establishment through two proxies

In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy 2.

The initial INVITE (F1) contains a pre-loaded Route header with the address of Proxy 1 (Proxy 1 is configured as a default outbound proxy for Alice). The request does not contain the Authorization credentials Proxy 1 requires, so a 407 Proxy Authorization response is sent containing the challenge information.

A new INVITE (F4) is then sent containing the correct credentials and the call proceeds.

The call terminates when Bob disconnects by initiating a BYE message.

Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header.

The ACK (F15) and BYE (F18) both have a Route header.



Unsuccessful temporarily unavailable

In this scenario, Bob initially sends a 180 Ringing response to Alice, indicating that alerting is taking place.

However, then a 480 Unavailable is then sent to Alice. This response is acknowledged and then proxied back

to Alice.


Alice Proxy 1 Proxy 2 Bob | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3|--------------->| INVITE F4 | |<---------------| 100 F5 |--------------->| | |<---------------| 180 F6 | | | 180 F7 |<---------------| | 180 Ringing F8|<---------------| | |<---------------| | 480 F9 | | | |<---------------| | | | ACK F10 | | | 480 F11 |--------------->| | |<---------------| | | | ACK F12 | | |480 Temporarily |--------------->| | | Unavailable F13| | | |<---------------| | | | ACK F14 | | | |--------------->| | | | | | |


Forking proxy

• Used if a particular user is registered at several locations

• Stateful!– Proxy remembers that it has two sessions

pending and it cancels the one the moment the other responds

• The “branch” parameter in the “via” header allows to distinguish among forked requests (and responses)



SDP

• Session Description Protocol– Which is not a protocol...– ...but a description language for media flows

• Convey sufficient information to participate in a multimedia session

• Independent of SIP– But they work nicely together


SDP message info

• SDP includes description of:– Media to use

• Codec• Sampling rate

– Media destination• IP address and port number

– Session name and purpose– Times the session is active– Contact information


SDP message example

v=0

o=alice 28908044538 289080890 IN IP4 193.175.132.118

s=Wedding Proposal

[email protected]

c=IN IP4 126.16.69.4

t=28908044900 28908045000

m=audio 49170 RTP/AVP 15 98

a=rtpmap:15 G728/8000

a=rtpmap:98 L16/11025/2

m=audio 4666 RTP/AVP 4

a=rtpmap:4 G723/8000


SDP capability negotiation

• Caller offers set of possible media• Callee accepts or rejects every one of them

– If several chosen, re-invite

• If none acceptable, warning sent back and re-invite

• Alternative: Use the OPTIONS method– Query the callee's capabilities prior to INVITE


SDP examples

1.Successful capability selection with SDP2.Re-invite after capability exchange with SDP3.Capability query with OPTIONS

(Taken from Collins)


Example 1:

Successful

capability

selection


Example 2:

Re-Invite after

capability

exchange


Example 3:

capability

query with

OPTIONS


For next class

Find an article on any of the following topics:- SIP + WLANs- Mobile P2PSIP- Application layer mobility using SIP

Small presentation (5-10 slides) each during seminar

Short report (max. 2 pages) on paper send by Friday, 29 January

Date post:	13-Jan-2016
Category:	Documents
Upload:	liesel
View:	33 times
Download:	2 times

SIP

Documents