Analisis Profundo de SIP

8/13/2019 Analisis Profundo de SIP

1/87

Session Initiation Protocol (SIP)

Extrado del curso Internet Telephony de MFC, Taiwan


2/87

2

Introduction

A powerful alternative to H.323

More flexible, simpler

Easier to implement

Advanced features

Better suited to the support of intelligent user

devices

A part of IETF multimedia data and controlarchitecture

SDP, RTSP (Real-Time Streaming Protocol),

SAP (Session Announcement Protocol)


3/87

3

The Popularity of SIP

Originally Developed in the MMUSIC

A separate SIP working group

RFC 3261

Many developersSIP + MGCP/MEGACO

The VoIP signaling in the future

back-off or SIPit (SIP Interoperability Tests)

Test products against each other

Organized by SIP Forum


4/87

4

The 18th SIPit event in Tokyo, Japantook place April17-21, 2006, and will be hosted byJPNICThe 17th SIPit event in Stockholm, Sweden tookplace 2005-09-11 to 2005-09-16 and was hosted byHotsip

The 16th SIPit event in Banff, Canada took place2005-04-04 to 2005-04-08 and was hosted by JasomiNetworks

The 15th SIPit eventin Taiwan took place 2004-08-

23 to 2004-08-27 and was hosted by CCL/ITRIThe 14th SIPit eventin Cannes, France took place2004-02-08 to 2004-02-13 and was hosted by ETSI
http://www.hotsip.com/http://www.jasomi.com/http://www.jasomi.com/http://www.sipit15.itri.org.tw/http://www.itri.org.tw/http://www.etsi.org/plugtests/SIPIT14.htmhttp://www.etsi.org/plugtests/home.htmhttp://www.etsi.org/plugtests/home.htmhttp://www.etsi.org/plugtests/SIPIT14.htmhttp://www.itri.org.tw/http://www.sipit15.itri.org.tw/http://www.jasomi.com/http://www.jasomi.com/http://www.hotsip.com/


5/87

5

SIP ArchitectureA signaling protocol

The setup, modification, and tear-down ofmultimedia sessions

SIP + SDP

Describe the session characteristics

Separate signaling and media streams


6/87

6

SIP Network Entities

Clients

User agent clients

Application programs sending SIP requests

Servers Responds to clients requests

Clients and servers may be in the same

platform

Proxy

Acts as both clients and servers


7/87

7

Four types of servers

Proxy servers Handle requests or forward requests to other servers

Can be used for call forwarding


8/87

8

Redirect servers

Map the destination address to zero or more new

addresses

Do not initiate any SIP requests


9/87

9

A user agent server

Accept SIP requests and contacts the user

The user responds an SIP response

A SIP device

E.g., an SIP-enabled telephone

A registrar

Accepts SIP REGISTER requests

Indicating the user is at a particular address

Typically combined with a proxy or redirect server


10/87

10

SIP Call Establishment

It is simple

A number of interim

responses


11/87

11

SIP Advantages

Attempt to keep the signaling as simple as

possible

Offer a great deal of flexibility

Various pieces of information can be included

within the messages

Including non-standard information

Enable the users to make intelligent decisions

The user has control of call handling

No need to subscribe call features


12/87

12

Call Completion to Busy Subscriber service


13/87

13

Overview of SIP Messaging Syntax

Text-based Similar to HTTP

SIP messages

message = start-line

*message-header CRLF

[message-body]

start-line = request-line | status-line

Request-line specifies the type of requestThe response line

The success or failure of a given request


14/87

14

Message headers

Additional information of the request or response E.g.,

The originator and recipient

Retry-after header

Subject header

Message body

Describe the type of session

The media format

SDP, Session Description Protocol

Could include an ISDN User Part message

Examined only at the two ends


15/87

15

SIP Requestsmethod SP request-URI SP SIP-version

CRLFrequest-URI

The address of the destination

Methods

INVITE, ACK, OPTIONS, BYE, CANCLE,

REGISTER

extensions: INFO, REFER, UPDATE,

INVITE

Initiate a session

Information of the calling and called parties

The type of media

= IAM (initial address message) of ISUP

ACK only the final response


16/87

16

BYE Terminate a session

Can be issued by either the calling or called party

Options

Query a server as to its capabilities A particular type of media

The response if sent an INVITE

CANCEL

Terminate a pending request

E.g., an INVITE did not receive a final response


17/87

17

REGISTER Log in and register the address with a SIP server

all SIP servers multicast address (224.0.1.75)

Can register with multiple servers

Can have several registrations with one server INFO

RFC 2976

Transfer information during an ongoing session

DTMF digits account balance information

Mid-call signaling information generated in another network


18/87

18

SIP Responses

SIP version SP status code SP reason-phrase CRLFreason-phrase

A textual description of the outcome

Could be presented to the user

status code A three-digit number

1XX Informational

2XX Success (only code 200 is defined)

3XX Redirection

4XX Request Failure

5XX Server Failure

6XX Global Failure

All responses, except for 1XX, are considered final

Should be ACKed


19/87

19

One number service


20/87

20

SIP Addressing

SIP URLs (Uniform Resource Locators)

user@host

E.g., sip:[email protected]

sip:[email protected]

Supplement the URL

sip:[email protected];user=phone sip:user:password@host:port;uri-parameters?headers
mailto:user@hostmailto:user@host


21/87

21

Message HeadersProvide further information about the

message

+information elements

E.g.,

To:header in an INVITE The called party

From:header

The caling party

Four main categories General, request, response, and entity headers


22/87

22

General Headers

Used in both requests and responses

Basic information

E.g., To:, From:, Call-ID:,

Contact:

A URL for future communication

May be different from the From: header

Requests passed through proxies


23/87

23

Request Headers

Apply only to SIP requests Addition information about the request or the client

E.g.,

Subject:

Priority:, urgency of the request Authorization:, authentication of the request originator

Response Headers

Further information about the response

E.g., Unsupported:, features

Retry-After


24/87

24

Entity Header

Session information presented to the user Session description, SDP

The RTP payload type, an address and port

Content-Length, the length of the message body

Content-Type, the media type of the message Content-Encoding, for message compression

Content Disposition,

Content-Language,

Allow, used in a Request to indicate the set ofmethods supported

Expires, the date and time


25/87

25

Example of SIP Message Sequences

Registration Via:

Call-ID:

host-specific Content-Length:

Zero, no msg body

Cseg: Avoid ambiguity

Expires: TTL

0, unreg

Contact:

*


26/87

26

Invitation

A two-party call

Subject:

optional

Content-Type:

application/sdp


27/87

27


28/87

28

Termination of a Call

Cseq:

Has changed


29/87

29

Redirect Servers

An alternative address

302, Moved temporarily

Another INVITE

Same Call-ID

Cseq ++


30/87

30

Proxy Servers

Entity headers are

omitted

Changes the Req-URI

Via: The path

Loop detected, 482

For a response

The 1stVia: header Checked

removed


31/87

31


32/87


33/87

33

Forking Proxy

fork requestsA user is registered at

several locations

;branch=xxx


34/87

34


35/87

35

The Session Description Protocol

The message body SDP, RFC 2327

The Structure of SDP

Session Level Info

Name

The originator

The time

Media Level Info

Media type

Port number

Transport protocol

Media format


36/87

36

SDP session description structure


37/87

37

SDP Syntax

A number of lines of text

In each line

field=value

Session-level fields firstMedia-level fields

Begin with media description field (m=)


38/87

38

Mandatory Fields

v=(protocol version) o=(session origin or creator and session id)

s=(session name), a text string

t=(time of the session)

t= NTP time values in seconds

m=(media)

m=

Media type The transport port

The transport protocol

The media format, an RTP payload format


39/87

39

Optional Fields (1)

i=(session information) A text description

At both session and media levels

u=(URI of description)

Where further session information can be obtained Only at session level

e=(e-mail address)

Who is responsible for the session

Only at the session level p=(phone number)

Only at the session level


40/87

40

Optional Fields (2)

c=(connection information)

Connection type, network type, and connection

address

At session or media level

b=(bandwidth information)

In kilobits per second


r=

For regularly scheduled session

How often and how many times


41/87

41

Optional Fields (3)

z=(timezone adjustments)

z=

....

For regularly scheduled session

Standard time and Daylight Savings Time

k=(encryption key)

k=:

An encryption key or a mechanism to obtain it


a=(attributes)

Describe additional attributes


42/87

42

Ordering of Fields

Session Level Protocol version (v)

Origin (o)

Session name (s)

Session information (i)

URI (u) E-mail address (e)

Phone number (p)

Connection info (c)

Bandwidth info (b)

Time description (t)

Repeat info (r)

Time zone adjustments (z)

Encryption key (k)

Attributes (a)

Media level

Media description (m)

Media info (i)

Connection info (c)

Optional if specified at

the session level

Bandwidth info (b)

Encryption key (k)

Attributes (a)


43/87


44/87

44

Subfields (2)

Connection Data The network and address at which media data are to

be received

Network type, address type, connection address

c=IN IP4 224.2.17.12/127

Media Information

Media type

Audio, video, application, data, or control

Port, 1024-65535

Format

List the various types of media

RTP/AVP payload types

m= audio 45678 RTP/AVP 15 3 0

G.728, GSM, G.711


45/87

45

Subfields (3)

Attributes

Property attribute

a=sendonly

a=recvonly

value attribute

a=orient:landscape

rtpmap attribute

The use of dynamic payload type

a=rtpmap: /[/].

m=video 54678 RTP/AVP 98

a=rtpmap 98 L16/16000/2


46/87

46

Usage of SDP with SIP

SIP for the establishment of multimedia

sessions

SDPa structured language for describingthe sessions

The entity header


47/87

47

Negotiation of Media

Fig 5-15 G.728 is selected

If a mismatch

488 or 606

Not Acceptable

A Warning header

INVITE with multiple

media streams

Unsupported

should also be

returned

With a port

number of zero


48/87

48


49/87

49

Offer/answer


50/87

50


51/87

51

OPTIONS Method

Determine the

capabilities of a potential

called party


52/87


53/87

53

183 Session-Progress Message

The addition of a new response Status code 183

To open a one-way media path From the called party to calling party

convey information about the progress of the call that

is not otherwise classified Tones or announcements

ACM (address complete message) of SS7

For SIPPSTNSIP connections

When a temporary media stream is needed

Note that alerting signal can be Status code 180 (ringing)

The temporary media stream will be terminated As soon as the called user answers


54/87

54

The SIP Supported Header

The Require header UACs tell UASs about options that the UAC expects

the UAS to support

require: 100rel

may receiver 420 (Bad Extension)

The Supported header enumerates all the extensions supported by the UAC

or UAS

Included in both requests and responses BYE, CANCEL, INVITE, OPTIONS and REGISTER

Should not be included in the ACK

421, extension required The UAS needs a particular extension to process the

request


55/87

55


56/87

56

SIP INFO Method

A new SIP methodRFC 2976

The transfer of information in the middle of a call

DTMF digits, account-balance information, mid-call signaling information (from PSTN)

A powerful, flexible tool to support new services

e.g., the users prepaid account balance


57/87

57

SIP Event Notification

SIP-specific event notification

be informed of some event(s)

RFC 3265SUBSCRIBE

subscribe to certain event

Event: header

NOTIFY

inform the user

200 (OK) response


58/87

58


59/87

59

SIP for Instant Messaging

SIMPLE - SIP for Instant Messaging andPresence Leveraging Extensions a working group

RFC 3994, 3856

The exchange of content between a set ofparticipants in near real time IMs are usually grouped together into brief live

comversations

MESSAGE request, RFC 3994 a message body in the form text/plain, or

message/cpim (common presence and instantmessage) using XML


60/87

60

Doesntestablish a

SIP dialog Can be

associatedwith anexisting SIPdialog

Contact:header isforbidden

No Record-Route: orRoute:

header


61/87

61


62/87

62

REFER MethodRFC 3515

Instruct the receiver to contact a third party

Refer-to:

Can be interpreted as an implicit

SUBSCRIBE The sender will be notified the result

202 (accepted)

An extensionA SIP message is tunneled within a SIP

message

Refer-by:


63/87

63


64/87


65/87

65

Reliability of Provisional Responses

Provisional Responses

100 (trying), 180 (ringing), 183 (session in

progress)

Are not answered with an ACK

If the messages is sent over UDP

Unreliable

Lost provisional response may causeproblems when interoperating with other

network

180, 183 Q931 alerting or ISUP ACM

To drive a state machine


66/87

66

RSeq Response seq

+1, whenretxm

Rack Response

ACK

PRACK Prov Resp

ACK

the option tag 100rel

Should not Apply to 100

hop-by-hop


67/87

67


68/87

68

UPDATE Method

RFC 3311

Change the media format in the early state

re-INVITE cannot be used; it changes the state

Can be used to reserve network resources

Integration of SIP and Resource


69/87

69

g

Mang

RFC 3312

The signaling might take a different path from

the mediaAssume resource-reservation mechanisms

available (Chapter 8)

On a per-session basis

On an aggregate basis

A new SIP header in the INVITE

Resources reservation is needed

The user should not yet be alerted


70/87

70

Integration of Resource Management and

SIP for IP Telephony A new method, PRECONDITION-MET

The far-end phone will not ring until

Also specifies extensions to SDP

Can define any number of preconditions in SDP

without revise SIP every time

The response is sent using reliable signaling

Once the resource is reserved

An UPDATE request is sent

If failed, could select a lower-bandwidth codec


71/87

71


72/87

72

The preconditions/requirements in the SDP

Three status

desired, current, and confirmed

Resource reservation

end-to-end (e2e), local, and remote

Purpose

send, recv, and sendrecv

Strength

mandatory, optional, none and failure


73/87

73

Examples

m=audio 4444 RTP/RTCP 0

a=curr: qos e2e none

a=des: qos mandatory e2e sendrecv

a=curr: qos e2e send

a=des: qos mandatory e2e sendrecv

a=curr: qos e2e sendrecv a=des: qos mandatory e2e sendrecv


74/87

74


75/87

Call Forwarding


76/87

76

Call Forwarding

On busy

486, busy here

Consultation Hold


77/87

77

Consultation Hold

A SIP UPDATE


78/87

78

Interworking

PSTN Interworking A SIP URL

A network gateway

Fig. 5-27

SIP to PSTN call

Fig. 5-28

PSTN to SIP call

PSTNSIPPSTN

MIME media types

For ISUP and QSIG


79/87

79


80/87

80

Interworking with H 323


81/87

81

Interworking with H.323

An Internet draftSIP-H.323 interworking gateway


82/87

82


83/87

83


84/87

84


85/87

85


86/87


87/87

Muchas gracias

Ing. Fernando Fontn

Santa Cruz de la Sierra, Bolivia

J i d 2006

Extrado del curso Internet Telephony de MFC, Taiwan

Documents

Analisis Profundo de SIP