VoIP with SIP. Session Initiation Protocol RFC-3261/RFC

(1)

VoIP with SIP

Session Initiation Protocol RFC-3261/RFC-2543

(2)

Legacy Telephone

(3)

Legacy Telephone

(4)

Legacy Telephone

(5)

Legacy Telephone

(6)

Legacy Telephone

(7)

Legacy Telephone

(8)

Legacy Telephone

(9)

Legacy Telephone

(10)

Legacy Telephone

(11)

Legacy Telephone

(12)

Legacy Telephone

(13)

Legacy Telephone

(14)

Legacy Telephone

(15)

Legacy Telephone

(16)

Legacy Telephone

(17)

Legacy Telephone

(18)

Legacy Telephone

(19)

Legacy Telephone

(20)

Legacy Telephone

(21)

Legacy Telephone

(22)

Legacy Telephone

(23)

Legacy Telephone

(24)

Legacy Telephone

(25)

Legacy Telephone

(26)

Legacy Telephone

(27)

Legacy Telephone

(28)

Legacy Telephone

(29)

Legacy Telephone

(30)

•

Use SS7 as out band signaling

•

Time Division Multiplexing

•

T1 / E1 / SDH as trunk

•

DS0 64Kbps per channel

•

Routing based on dialing plan

Legacy Telephone

(31)

Voice over IP

(32)

Voice over IP

(33)

Voice over IP

•

Signaling out band with SIP / H.323

•

Packet Switching

•

Transport with IP/UDP/RTP

•

With G.711/G.723/G.726/G.729 Codec

•

Routing based on IP address

(34)

SIP Overview

Internet telephony use a verity of signaling protocols, such as H.323, SIP, MGCP and H.248 (MEGACO) for initiating VoIP call.

However, SIP seems to overwhelm all the others, mainly due to the fact that is has been adopted by various standardization organizations i.e. IETF, ETSI, 3GPP as the protocol for both wireline and wireless world in the Next Generation Networks (NGN) era.

(35)

SIP is an application layer signaling protocol for

creating, modifying and terminating multimedia sessions with one or more participants.

A SIP message can either be a REQuest or

ACKnowledgment to a request, consisting of the header field and the message body.

SIP message are text-based and are similar to HTTP message format. The message body is either used to describe session requirements or to encapsulate

various types of signaling.

(36)

SIP message must also identify the requested resource, which corresponds to a unique address. SIP addresses follow the general form of Mail addressing scheme.

An example of a SIP address are:

sip:[email protected]

(37)

SIP Protocol

SIP works in concept with several other protocols and is only involved in the signaling potion of a

communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use, what codec being used etc.

In typical use, SIP sessions are simply packet streams of the Real-time Transport Protocol (RTP).

RTP is the carrier for the actual audio or video content itself.

(38)

SIP Server requirement

•

^Proxy

•

Registration

•

^Refer

•

^Redirect

(39)

Proxy Service

The proxy server receives SIP requests and forwards them on behalf of the requester and consults a

database, generically called a location services, that

contains the current IP address of where the receiver stand with.

The SIP Proxy is responsible to routing all SIP message to their destinations.

(40)

Registration Service

Registration is one way that the proxy server can learn the current location of receiver.

When initialization, at periodic intervals, user send a REGISTER messages to a SIP register server, the

REGISTER messages associate SIP URI logged. The

register writes the association, also called a binding to a database, called the location services, where it can be

used by the proxy server.

Often, a register and proxy is co-located and in

(41)

The SIP Register handles the registration services for caller and receiver located.

Detail of locating SIP Server in RFc-3263

(42)

Refer Service

This extension provides a mechanism where one party (the referrer) provides a seconds party (also the

referrer) with an arbitrary Uniform Resource Identifiers (URI) to reference.

SIP Refer can be used to enable many applications, including call Transfer.

SIP refer is reference to RFC-3892

(43)

SIP Inside

SIP messages is similar to HTTP messages and shares some of its design principles:

It is human readable and request-response structured.

SIP proponents also claim it to be simpler than H.323.

(44)

SIP Request

•

^RFC-3261

•

^RFC-3265

(45)

RFC-3261

•

^INVITE

•

^ACK

•

^BYE

•

^CANCEL

•

^OPTIONS

•

^REGISTER

SIP uses six type of require messages

(46)

REGISTER

REGISTER:

Registers the address listed in the “To header” field with a SIP server.

(47)

REGISTER

(48)

REGISTER

(49)

REGISTER

(50)

INVITE

INVITE :

Indicates a client being invited to participate in a call session.

(51)

INVATE

(52)

INVATE

(53)

INVATE

(54)

INVATE

(55)

ACK

ACK:

confirms that the client has received a final response to an INVITE request.

(56)

BYE

BYE:

Terminates a call and can be sent by either the caller or the callee.

(57)

CANCEL

CANCEL:

Cancels any pending searches but does not terminate a call that has already been accepted.

(58)

OPTIONS

OPTIONS:

Queries the capabilities of servers.

(59)

SIP message pass

(60)

SIP message pass

(61)

SIP message pass

(62)

SIP message pass

(63)

SIP message pass

(64)

SIP message pass

(65)

SIP message pass

(66)

SIP message pass

(67)

SIP message pass

(68)

SIP message pass

(69)

SIP message pass

(70)

SIP message pass

(71)

SIP message pass

(72)

RFC-3265

•

^SUBSCRIBE

•

^NOTIFY

Extends the basic request messages to support notification.

(73)

SUBSCRIBE

SUBSCRIBE:

Subscribes for a Event of Notification from the Notifier.

(74)

NOTIFY

NOTIFY:

Notify the subscriber of a new event.

(75)

SIP Response

SIP responses are the codes used by Session Initiation Protocol for communication. They complement the SIP Requests, which are used to initiate action such as a

phone conversation.

(76)

SIP Response type contents

•

1xx : Informational

•

2xx : Successful

•

3xx : Redirection

•

4xx : Client Failure

•

5xx : Server Failure

•

6xx : Global Failure

(77)

Informational

•

100 : Trying

•

180 : Ringing

•

181 : Call is being forwarded

•

182 : Queued

•

183 : Session progress

(78)

Successful

•

^{200 : OK}

•

202 : Accepted ( Used for referrals )

(79)

Redirection

•

300 : Multiple choices

•

301 : Moved permanently

•

302 : Moved temporarily

•

305 : Use proxy

•

380 : Alternative service

(80)

Client Failure

•

400 : Bad request

•

401 : Unauthorized (Only for Registers)

•

402 : Payment required

•

403 : Forbidden

•

404 : User not found

•

405 : Method not allowed

•

(81)

Client Failure

•

407 : Proxy authentication required

•

408 : Request timeout

•

410 : User gone

•

413 : Request entity too large

•

414 : Request URI too long

•

415 : Unsupported media type

•

416 : Unsupported URI scheme

(82)

Client Failure

•

420 : Bad SIP extension

•

421 : Extension required

•

423 : Interval too brief

•

480 : Temporarily unavailable

•

481 : Call / Transaction does not exist

•

482 : Loop detected

(83)

Client Failure

•

483 : Too many hops

•

484 : Address incomplete

•

485 : Ambiguous

•

486 : Busy here

•

487 : Request terminated

•

488 : Not acceptable here

(84)

Client Failure

•

491 : Request pending

•

493 : Undecipherable

•

494 : Security agreement required

(85)

Server Failure

•

500 : Server internal error

•

501 : Not implemented

•

502 : Bad gateway

•

503 : Service unavailable

•

504 : Server timeout

•

505 : Version not supported

•

(86)

Global Failure

•

600 : Busy everywhere

•

603 : Decline

•

604 : Does not exist anywhere

•

606 : Not acceptable

(87)

SIP call procedure

(88)

SIP call procedure

(89)

SIP call procedure

(90)

SIP call procedure

(91)

SIP call procedure

(92)

SIP call procedure

(93)

SIP call procedure

(94)

SIP call procedure

(95)

SIP call procedure

(96)

SIP call procedure

(97)

In Function point of view:

SIP Register and Proxy service administrate SIP messages.

In Protocol point of view:

SIP REGISTER and INVITE messages are the pre- dominant messages used by the SIP protocol.

Summary

(98)

SIP clients traditionally use TCP and UDP 5060 to connect to SIP servers and other SIP endpoints.

All Audio and Video communications are done over separate session protocols, typically RTP.

(99)

RTP Inside

RTP - Real-time Transport Protocol

RTP defines a good standardized packet format for delivering audio and video over the Internet. It was developed by the IETF and first published in 1996 as RFC-1889 which was obsoleted in 2003 by RFC-3550.

(100)

RTP Header

•

Payload Type : 7 bit

•

Sequence number : 16 bit

•

Time stamp : 32 bit

•

Synchronization source identifier : 32 bit

•

Miscellaneous Field ...

(101)

RTP Header

Time Stemp

Synchronization Source Identifier

Contributing Source ID

Contributing Source ID ...

Sequence P Type

M CC X

P VER

0 2 3 4 8 9 16 31

(102)

The minimal 12 bytes of the RTP header, combined

with 20 bytes of IP header and 8 bytes of UDP header, create a 40 byte IP/UDP/RTP header.

The RTP packet has a payload of approximately 20 to 150 bytes for audio applications that use compressed payloads. It is very inefficient to transmit the IP/UDP/

RTP header without compressing it.

The RTP header compression compresses the IP/UDP/

RTP header in an RTP data packet from 40 bytes to

RTP Header compress

(103)

RTP Header Compress

IP UDP RTP Payload

Overhead

20 to 160 byte 20 byte 8 byte 12 byte

No Header Compression

Header Payload

20 to 160 byte 3 - 5

IP/UDP/RTP Header Compression

(104)

RTP Header compress

RTP header compression is a hop-by-hop compression scheme similar to RFC-1144 for TCP header

compression. The RFC-2507 for IP header compression.

Using RTP header compression can benefit both

telephony voice applications running over slow links.

The detail refer to RFC-2508

(105)

RTP/AVP

RTP Audio and Video payload Profile detail in RFC-3551/RFC-1890.

This profile defines aspects of RTP left unspecified in the RTP protocol definition. It is for use of the RTP, RCTP within Audio and Video multi-participant

conferences with minimal control. It provides interpretations of generic fields within the RTP

specification suitable for audio and video conferences, and define a set of default mapping from payload type

(106)

RTP/AVP payload type

Type Format Sampling Rate Rate

0 PCM u-Law 8 KHz 64 Kbps

1 1016 8 KHz 4.8 Kbps

3 GSM 8 KHz 13 Kbps

4 G.723 8 KHz

7 LPC 8 KHz 2.4 Kbps

8 PCM a-Law 8 KHz 64 Kbps

9 G.722 16 KHz 48 - 64 Kbps

14 MPEG-Audio 90 KHz

15 G.728 8 KHz 16 Kbps

18 G.729 8 KHz

26 Motion-JPEG Video

31 H.261 Video

(107)

RTCP Inside

RTCP - Real Time Control Protocol

RTCP to handle the SDP described the RTP use

multiple ports and crossed the NAT ports mapping problems, it is extension attribute to SDP.

Detail refer to RFC-3605/RFC-2377

In normally use, the RTP will use odd port and RTCP will use the RTP port + 1, for describe and report that RTP session status.

(108)

The RTCP attribute is used to document the RTP port used for media stream, when that ports is not the next higher port number following the RTP port described in the media line(not continue port number).

The RTCP attributes is a value attribute and follows the general syntax:

a=attribute:value

(109)

SDP Inside

SDP - Session Description Protocol is a format for describing streaming media initialization parameters.

It has been published by the IETF as RFC-4566/

RFC-2327

SDP is intended for describing multimedia sessions for the purposes of session announcement, session

invitation, and other forms of multimedia session initiation.

(110)

SDP started off as a component of the Session

Announcement Protocol (SAP), but found other uses in conjunction with RTP, SIP and just as a standalone

format for describing multicast sessions.

An SDP session description is entirely textual using the ISO-10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII

subset of UTF-8, but textual field and attribute values

(111)

•

Session initiation

•

Streaming media

•

Email and Web

•

Multicast session announcement SDP is be used in :

(112)

SDP terms

•

^Conference

•

^Session

•

Session Announcement

•

Session Advertisement

•

Session Description

(113)

Conference

Conference :

It is a set of two or more communicating users along with the software they are using.

(114)

Session

Session :

Session is the multimedia sender and receiver and the following stream of data.

(115)

Session announcement

Session Announcement :

A Session announcement is a mechanism by which a

session description is conveyed to users in a proactive fashion, i.e. the session description was not explicitly requested by the user.

(116)

Session advertisement

Session advertisement :

Same as session announcement.

(117)

Session description

Session description :

A well defined format for conveying sufficient information to discovery and participate in a multimedia session.

(118)

SDP Messages

SDP session description consists of a number of lines of text of the form :

type=value

Where type must be exactly one case-significant

character and value is structured text whose format depends on type.

(119)

Session description

•

v= protocol version

•

o= originator and session identifier

•

s= session name

•

i=* session information

•

u=* URI of description

•

e=* email address

(120)

Session description

•

p=* phone number

•

c=* connection information

•

b=* zero or more bandwidth information lines

•

z=* time zone adjustments

•

k=* encryption key

(121)

Time description

•

t= time the session is active

•

r=* zero or more repeat times

(122)

Media description

•

m= media name and transport address

•

i=* media title

•

c=* connection information

•

b=* zero or more bandwidth information lines

•

k=* encryption key

(123)

SDP Example

v=0

o=user1 2890844526 2890842807 IN IP4 192.168.64.4 s=Sd seminar

i=A seminar on the session description protocol u=http://www.here.com/SDP/sdp01.txt

[email protected] (User Who) c=IN IP4 224.2.17.12/127

t=2873397496 2873404696 a=recvonly

m=audio 3456 VAT PCMU m=video 2232 RTP H261

m=whiteboard 32416 UDP WB a=orient:portrait

Rewrite:

(session

(v 0)(o user1 2890844526 2890842807 IN IP4 192.168.64.4) (s Sd seminar)(i A Seminar on the session description protocol) (u http://www.here.com/SDP/sdp01.txt)

(e [email protected] (User Who))

(c IN IP4 224.2.17.12/127)(t 2873397496 2873404696)(a recvonly) (all

(media (m audio 3456 VAT PCMU))

(124)

Summary

The SDP is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers.

However, when the session crosses a Network Address Translated (NAT RFC-2766) device that also uses port mapping, the ordering of ports can be destroy by the translation. Use RTCP to resolve the problem.

(125)

SAP Inside

SAP - Session Announcement Protocol

SAP is a protocol for broadcasting multicast session information.

A SAP listening application can listen to the well-

known SAP multicast address and construct a guide of all advertised multicast sessions.

SAP was defined in RFC-2974

(126)

SAP typically uses SDP as the format of the session descriptions and the multicast sessions typically use RTP.

(127)

Quality of Service

Because the Audio and Video is delay sensitive, so when transmit it on net, Quality of Service is more important then others traffic. Traffic QoS can use Marking /

Filtering / Queueing methods to measure the traffic smoothly but will increase jitter.

So if traffic jam on net, the delay jitter still can not permit, but if the traffic path can be reservation

bandwidth for audio and video, then the service of quality will better.

(128)

RSVP

RSVP is a resource reservation setup protocol

designed for quality integrated services on Internet.

RSVP is used by a host to request specific qualities of service from the network for particular application

data streams of flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the

data path. Use RSVP to reservation bandwidth is be

(129)

RSVP requests resources in only one direction.

Therefore, RSVP treats a sender as logically distinct

from a receiver, although the same application process may act as both a sender and a receiver at the same

time. RSVP operates on top of IPv4 / IPv6, occupying

the place of a transport protocol in the protocol stack.

However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementation of RSVP will typically execute in the background, not in the data

(130)

RSVP is not routing by itself; RSVP is designed to

operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing databases to obtain routes. In the multicast

case, for example, a host sends RSVP messages to reserved resources along the delivery paths of that

group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of

those packets that are forwarded in accordance with

(131)

Reference Documents

(132)

VoIP Reference

•

RFC-2543/3261 SIP: Session Initiation Protocol

•

RFC-3263 SIP: Locating SIP servers

•

RFC-3265 SIP: Specific event notification

•

RFC-3892 SIP: Referred by mechanism

•

RFC-2327/4566 SDP: Session Description Protocol

•

RFC-1898/3550 RTP: A Transport Protocol for Real-Time Applications

•

RFC-1144 Compressing TCP/IP headers for low-speed serial links

•

(133)

•

RFC-3605 Real Time Control Protocol (RTCP) attribute in SDP

•

RFC-2974 Session Announcement Protocol (SDP)

•

RFC-3551 RTP Profile for Audio and Video (RTP/AVP) conferences with minimal control

•

RFC-3555 MIME Type Registration of RTP Payload formats

(134)

Based Protocols

•

RFC-768 User Datagram Protocol (UDP)

•

RFC-791 Internet Protocol (IP)

•

RFC-792 Internet Control Message Protocol (ICMP)

•

RFC-793 Transmission Control Protocol (TCP)

•

RFC-1112 Host Extenations for IP Multicasting (IGMP)

•

RFC-1738 Uniform Resource Locators (URL)

•

(135)

QoS Reference

•

RFC-2205 Resource Reservation Protocol (RSVP)

•

RFC-1349 Type of Service in the Internet Protocol Suite (ToS)

•

RFC-2474 Definition of the Differentiated Service Field (DS) in the IPv4 and IPv6 header

•

RFC-2475 An Architecture for Differentiated Services

•

RFC-2597 Assured Forwarding (AF) PHB Group

•

RFC-2598 An Expedited Forwarding (EF) PHB

•

RFC-3168 The Addition of Explicit Congestion Notification (ECN) to IP

(136)

•

RFC-3015 MEGACO Protocol Version 1.0 (ITU-T H.248)

•

RFC-2805 Media Gateway Control Protocol Architecture and Requirement (MGCP)

•

RFC-4612 Real-Time Facsimile (T.38) Audio/T38 MIME Sub-type Registration

•

RFC-ietf-avt-2833bis-15 RTP Payload for DTMF Signals

•

RFC-3047 RTP Payload format for ITU-T Recommendation G.722.1

IETF to ITU-T mapping