Abel Diego - Telefonía IP

2© 2005 Cisco Systems, Inc. All rights reserved. Cisco PublicVOIP PROTOCOLS OKON.JUL.2005

May 3rd, 2005

VoIPSignaling Protocols


ABEL DIEGO RODRABEL DIEGO RODRÍGUEZÍGUEZSYSTEMS ENGINEER MANAGER

Public Sector

Mexico

[email protected]

Who I am …


Agenda

1. Making the Rules for VoIP

2. Distributed Control

3. Centralized Control

4. Detailed Call Flows

5. Final Remarks


Making the Rules for VoIP 1


Making the Rules for VoIP

IETF (Internet Engineering Task Force)

The community of engineers that standardizes the protocols that define how the Internet and Internet Protocols work. http://www.ietf.org/

ITU (International Telecommunications Union)

An international organization within the United Nations System where governments and the private sector coordinate global telecom networks and services. http://www.itu.int/home/index.html


Defining the VoIP Protocols

H.323H.323

An ITU Recommendation that defines “Packet-based multimedia communications systems”. H.323 defines a distributed architecture for creating multimedia applications, including VoIP

SIPSIP

Defined as IETF RFC 2543. SIP defines a distributed architecture for creating multimedia applications, including VoIP

MGCPMGCP

Defined as IETF RFC 2705. MGCP defines a centralized architecture for creating multimedia applications, including VoIP

H.248H.248

An ITU Recommendation that defines “Gateway Control Protocol”. H.248 is the result of a joint-collaborate with the IETF. H.248 defines a centralized architecture, and is also known as “Megaco”

MegacoMegacoDefined as IETF RFC 2885. Megaco defines a centralized architecture


VoIP Signaling Protocols

Distributed ControlDistributed Control

H.323H.323

SIPSIP

Centralized ControlCentralized Control

MGCPMGCP

MEGACO / H.248MEGACO / H.248


Distributed Control 2


G

S

T

N

Terminal

Terminal

ServerServerServer

Distributed Arquitecture

Gateway

Gateway

Gateway

Gateway

Gateway

Gateway

IP

G

S

T

NH.323

H.323

SIP


Endpoint’s Requirement

Each endpoint (Terminal or Gateway) is required to perform the following function:s

Media GatewayConvertion of media (voice, video, etc) from one network to the other (ie: TDM to IP)

Signaling It exchanges information with other devices in both networks using some kind of protocol (i.e.: SS7 in TDM networks, SIP in IP networks, etc)

Call ControlControls the parts of the call state that pertain to connection control for its media channels. Manages the dial plan (who can call who… when)




Call ControlControls the parts of the call state that pertain to connection control for its media channels. Manages the dial plan (who can call who… when)


Media GatewayWHAT DO THEY DO






Call ControlHOW THEY DECIDE WHAT TO DO





Signaling HOW THEY EXCHANGE INFORMATION ON WHAT THEY WILL DO

Call ControlHOW THEY DECIDE WHAT TO DO


H.323


H.323 Background

ITU recommendation

v1 approved in 1996

v2 approved in January 1998

v3 approved in September of 1999

V4 approved in 2000

Defines multimedia applications over packet-based networks

Voice coding is a requirement

Leverages existing standards

Wide market acceptance

Facilitates interoperability between vendors

Cisco VoIP solutions are H.323 compliant


H.324Terminal

H.324Terminal

H.323Gatekeeper

H.323Gatekeeper

Packet Network

H.323Terminal

H.323Terminal

H.323Gateway

H.323Gateway

H.323MCUH.323MCU Scope of

H.323

PSTN ISDN

V.70Terminal

V.70Terminal

SpeechTerminalSpeech

TerminalH.320

TerminalH.320

TerminalSpeech

TerminalSpeech

Terminal

H.323 Components

e

GK


Scope of H.323 Recommendation

Video CodecH.261, H.263

Call ControlH.225.0

System ControlSystem Control

Audio CodecG.711, G.722,G.723, G.728,

G.729

RAS ControlH.225.0

RTP

RTCP

H.245 Control

Audio I/O Equipment

User Data Applications

T.120, etc.

SystemControl

UserInterface

Video I/O Equipment

H.225Layer

UDP

TCP

UDP

IP

ReceivePain

Delay(Sync)


H.245 (TCPDynamic Port)Open Logical Channel

Open Logical Channel Acknowledge

Capabilities Exchange / MSD

Media (UDP)RTP StreamRTP StreamRTCP StreamRTCP Stream

RTP StreamRTP Stream

VV

H.323Endpoint A

H.225 (TCP Port 1720)Setup

Alerting / Connect

H.323Endpoint B

VV

H.323 Signaling


Gatekeeper A Gatekeeper B

RRQ/RCF

ARQ

RRQ/RCF

LRQ

IP Network

Phone A

Gateway A Gateway B

H.225 (Q.931) Setup

H.225 (Q.931) Alert and Connect

H.245

RTP

ACF

LCF

VV

Basic H.323 Call

VV

ARQ

ACF

Phone B


H.225/H.245 Call Signalling

RTP Voice Bearer Traffic

H.225

RAS H.225 RAS

Directed Call Signalling

H.225/H.245Call Signalling

RTP Voice Bearer Traffic

H.225

RAS H.225 RAS

GK Routed Signalling (GRS)

GK Signalling Models

Cisco GKs do Direct mode only Many 3rd Party GKs are capable of both modes Scalability

Directed model scales better GK-based applications often require GRS

billingVPN servicescall deflection/control


SIP


The history of SIP

Session Initiation Protocol (SIP) is defined via RFC2543 on March

17, 1999. Work was initiated in the IETF’s MMUSIC working-group.

Additional “feature” drafts have been written to address issues which

concern SS7/ISUP handling, QoS, Alerting, DHCP, 3PCC, Firewalls

& NAT, etc…

IETF SIP-WG created in September, 1999

RFC2543bis (additions) created in April 2000.

Vendor interoperability testing done at the semi-annual SIP Bakeoff

(5th in August, 2000 - NYC, 6th in December in Silicon Valley)


SIP @ the IETF – A lot going on

RFC 2543

Bis-01

Bis-02

Bis-03

Bis-04

Bis-05

Bis-06

Bis-07

Bis-08

Bis-09

1999REFERSession Timer

PrivacyMessage-Waiting

Diversion3PCC

PresenceSIP-T

Tel: URLTRIPINFOT.38

SupportedCaller-Pref

PRACK / COMETEtc..

SIP-WG

SIMPLE-WG

SIPPING-WG

RFC 3261 JUNE 2002


SIP Basics—Architecture

SIP utilizes an Internet architecture, similar to the World Wide Web—

intelligent clients utilizing services within the network

Applications and SIP services can be distributed throughout the

network, with intelligence in the clients or in applications on the network

Additional services like presence, mobility, find-me/follow-me, etc. are

added into the network via basic SIP functionality or application servers

Application servers may use LDAP, XML, IMAP, TAPI/JTAPI, CGI, CPL,

etc. to provide the back-end services


Open/Standard Interface

Open/Standard Interface

Open Packet Telephony and SIP

Open Service Application Layer

Open Service Application Layer

Open Call Control LayerOpen Call Control Layer

Standards-Based Packet Infrastructure Layer

Standards-Based Packet Infrastructure Layer

Connection PlaneConnection Plane

Call Control PlaneCall Control PlaneProxy Servers• Quality Of Service (Q0S)• Security• Routing• Privacy Control

Services PlaneServices Plane

V

Voice Gateways•26xx/36xx/AS5300IP Phones/Endpoints•Telecaster 7960•Partner Phones

Redirect/Application Servers•IP Centrex•ASP•Residential


SIP Basics—Architecture

Legacy PBX

SIP User Agents (UA)

Application Services

SIPSIPSIPSIP

RTPRTP

SIPSIP

CAS or PRI

SIP Proxy, Registrar and Redirect Servers

Inte

llig

ent

Ser

vice

sIn

telli

gen

t S

ervi

ces

PSTN

E-MailLDAP

Oracle XMLCPL

3PCC


SIP Basics - Architectural Elements

Clients:Clients: User Agent Client (UAC) / User Agent Server (UAS)

Originate & Terminate SIP requests

Typically an endpoint will have both UAC & UAS, UAC for originating requests, and UAS for terminating requests

Servers:Servers:Proxy Server

Redirect Server

Registrar Server

Back-to-Back User Agent (B2BUA)


SIP Model

SIPSIP is based on an HTTP-like request/response transactiontransaction model

Each transaction consists of a requestrequest that invokes a particular METHOD,

or function, on the server and at least one responseresponse

A SIP SIP METHOD specifies the action that the requestor wants the server to

take

METHODS contains a number of header fields

Header fields are named attributes that provide additional information

about a message


SIP Methods

Consists of Requests and Responses

Requests

REGISTER: UA registers with Registrar ServerINVITE: request from a UAC to initiate a sessionACK: confirms receipt of a final response to INVITEBYE: sent by either side to end a callCANCEL: sent to end a call not yet connectedOPTIONS: sent to query capabilities outside of SDP

SIP Responses: 1xx - Informational Messages. 2xx - Successful Responses. 3xx - Redirection Responses. 4xx - Request Failure Responses. 5xx - Server Failure Responses. 6xx - Global Failures Responses.


SIP Methods

Newly Adopted Methods:

SUBSCRIBE & NOTIFY: used to identify device status / presence.

The foundation of SIP IM / Presence (IMPP).

INFO: a means of carrying “data” in a message body

REFER: the mechanism to initiate a Transfer

MESSAGE: the means of carrying “data” for SIP IMPP

Messages contain SIP Headers and Body

Body might be SDP or an attachment or some other application


SIP Headers

-----------------------------------------------------------------

SIP Header

-----------------------------------------------------------------

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.6.21:5060

From: sip:[email protected]

To: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 100 INVITE

Expires: 180

User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled

Accept: application/sdp

Contact: sip:[email protected]:5060

Content-Type: application/sdp


SIP - Register

SIP REGISTERREGISTER is sent by a non-Gateway UA (ie. SIP Phone) to the local SIP Server (Proxy/Redirect). The Server will give the REGISTER to the Registrar function. In this example, the SIP Phone is registering each DN line.

REGISTER sip:172.18.192.232 SIP/2.0Via: SIP/2.0/UDP 10.80.17.134:5060From: sip:[email protected]: sip:[email protected]: [email protected]: 100 REGISTERContact: <sip:[email protected]:5060>Expires: 3600Content-Length: 0

REGISTER sip:172.18.192.232 SIP/2.0Via: SIP/2.0/UDP 10.80.17.134:5060From: sip:[email protected]: sip:[email protected]: [email protected]: 100 REGISTERContact: <sip:[email protected]:5060>Expires: 3600Content-Length: 0


SIP - INVITE

INVITE sip:[email protected]:5060 SIP/2.0Expires: 180Content-Type: application/sdpVia: SIP/2.0/UDP 172.18.192.232:5060;branch=1FV1xhfvxGJOK9rWcKdAKOAVia: SIP/2.0/UDP 10.80.17.134:5060To: <sip:[email protected]>From: sip:[email protected]: [email protected]: 100 INVITEContact: sip:[email protected]:5060Content-Length: 219User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabledAccept: application/sdpRecord-Route: <sip:[email protected]:5060;maddr=172.18.192.232> v=0o=CiscoSystemsSIP-IPPhone-UserAgent 17045 11864 IN IP4 10.80.17.134s=SIP Callc=IN IP4 10.80.17.134t=0 0m=audio 29118 RTP/AVP 0 101a=rtpmap:0 pcmu/8000a=rtpmap:101 telephone-event/8000


Simplified SIP Call Flow

200 (OK)200 (OK)

180 (Ringing)180 (Ringing)

ACKACK

RTP MEDIA PATH

BYEBYE RELEASE

200 (OK)200 (OK)Call Teardown

MediaPath

Call Setup

INVITE

GatewayUser Agent

INVITE

Proxy Server

SETUP

PROCEEDING

ANSWER


SIP - How the pieces fit in

User Agent

1 - INVITE

2 - INVITE

3 - 3XX Redirect

4 - INVITE

5 - 200 OKAY

6 - 200 OKAY

RTPV

SIP Proxy ServerSIP Redirect Server

SIP User AgentSIP User Agent


Centralized Control 3


Centralized Call Control

484848


Distributed Gateway Model

GatewayGateway GatewayGatewayIPIP

H.323

SIP



GatewayGatewayIPIP

H.323

SIP

GatewayGateway

GatewayGateway

MGCMGC

MGMGSGSG



Media Gateway Media Gateway ControllerController

Signaling Signaling GatewayGateway

Media GatewayMedia Gateway

IPIP




Signalling Signalling GatewayGateway



The media gateway converts media provided in one type of network to the format required in another type of network; the gateway shall be capable of full duplex audio translations.








Media Gateway ControllerMedia Gateway ControllerControls the parts of the call state that pertain to connection control for media channels in one or more media gateways (also referred to as a call agent, or the industry term “Softswitch”)






Signaling GatewaySignaling GatewayThe Signaling Gateway is in the signaling (NOT media) path between SS7/ISDN signaling element, and call agent. Transforms SS7/ISDN signaling for transport on IP network. Signaling backhaul to media gateway controller.







sigtran megaco

mmusic

SCTP, IUA, M2UA, M2PA, M3UA, SUA,

V5UA

MGCP, MEGACO

SIP, SDP,SAP

Q.1901 (Q.BICC)

H.323

H.248

IETF stdsIETF stds

ITU stdsITU stds





sigtran megaco

mmusic

SCTP, IUA, M2UA, M2PA, M3UA, SUA

MGCP, MEGACO

SIP, SDP,SAP


E1/PRI

E1/R2






E1/PRI

E1/R2

Media GatewayMedia GatewaySignaling Signaling GatewayGateway

SS7






sigtran megaco

mmusicGateway

Gateway

Gateway

GatewayPSTN

IP

GATEWAY


Distributed Arquitecture (ITU-T)




Gateway

Gateway

Gateway

GatewayPSTN

IP

H.323

GATEWAY

H.248H.248


Distributed Arquitecture (IETF)




Gateway

Gateway

Gateway

GatewayPSTN

IPSIP

GATEWAY

MGCPMGCP

MEGACOMEGACO






Gateway

Gateway

Gateway

GatewayPSTN

IP

H.323

SIP

GATEWAY

MGCPMGCP

H.248H.248


Recommendation H.248H.248 defines the protocols used between

elements of a physically decomposed multimedia gatewayphysically decomposed multimedia gateway,

used in accordance with the architecture as specified in

Recommendation H.323H.323.

There are no functional differences from a system view

between a decomposed gateway, with distributed sub-

components potentially on more than one physical device, and a

monolithic gateway such as described in Recommendation

H.246H.246.

H.248/MEGACOScope

Taken from the H.248 Recommendation (11/00)


MGCP Concept

“MGCP is designed as an internal protocol within a distributed system that appears to the outside as a single VoIP gateway.”

RFC2705bis


MGCP


MGCP Overview

Media Gateway Control Protocol

IETF draft<draft-huitema-MGCP-v0r1-01.txt>

Dumb endpoint architecture

Centralized control architecture

Built as an extension to SGCP (Simple Gateway Control Protocol)


History

SGCP (Simple Gateway Control Protocol)Designed by Bellcore and Cisco.

IPDC (Internet Protocol for Device Control)Design by Level 3 in conjunction with many vendors including Cisco.

MGCPMGCP is the result of merging SGCP and IPDC.


MGCP versions

First draft dated Oct 11, 1998

A relatively stable version 0.1 dated Nov 9, 1998 <draft-huitema-MGCP-v0r1-01.txt>

MGCP 1.0 arrived at information RFC status on October, 1999 (RFC 2705)

MGCP 1.0 bis arrived at information RFC status on January, 2003 (RFC 3435)

MGCP is being extended with new packages:

RFC 3064: CAS PACKAGE

RFC 3149: Business Phone PACKAGE


High Level Concept

Media Gateway (MG) contains “simple” endpoints

Services provided by “intelligent” Media Gateway Controller (MGC) or Call Agent (CA)

Endpoint provides user interactions, CA provides “centralized” call intelligence

Master/Slave relationship between CA and MG

“Simple” endpoint executes small set of simple transactions as instructed by CA

New services introduced by CA

Inexpensive endpoint can be mass-produced


H.248 / MEGACO


MEGACO Benefits

MEGACO is an adopted IETF/ITU standard

Cleaner connection model

Same things can be done in MGCP, but MEGACO has cleaner model

Better multimedia support

Theoretically yes via support of multiple streams, but more definition is required:

Has video support been defined?

Synchronization of voice/video/data been defined?


Why should I deploy MGCP now if MEGACO is the official standard?

MGCP functionally equivalent to MEGACOMEGACO

MGCP is more mature protocol and is already in service provider betas

Interoperability and deployment issues have yet to be resolved in MEGACOMEGACO

Limited choice of call agents vendors with MEGACOMEGACO implementation


Voice Myths

Networks can only be built one way

Networks will converge to IP

Myths Facts

Networks will only use one protocol

All networks will converge

H.323, SIP, MGCP and H.248/Megaco will all be present in VoIP networks

VoIP allows centralized or distributed architectures


MGCP versus Megaco

Contrary to Popular Belief Megaco is not going to replace MGCP:

MGCP (NCS and TGCP) are PacketCable Specs

MGCP in the form of NCS and TGCP profiles are ITU-T recommendations (J.162 and J.171)

MGCP has continued to develop:

2705bis and basic packages are in the IETF editor’s queue (to be informational RFC’s); 2705bis allows significant extensibility mechanisms for the base protocol

IANA is in the process of setting up registration for MGCP packages

Additional packages: RFC 3064, bulk audits etc. continue to be developed

The Use of Megaco over MGCP or vice versa is strictly a marketing issue (there is no significant technical advantage of one over the other);

Example: MGCP limited to voice media (package extension all that’s required)


Final Remarks 4


• There are different VoIP protocols today, with different levels of maturity and different conceptual models

• H.323 and SIP are Distributed protocols (the intelligence is distributed)

• MGCP and MEGACO are Centralized protocols (the intelligence is centralized)

• VoIP networks, today, include a mix of these protocols and will increasingly do so in the future

VoIP Signaling ProtocolsConclusions

Abel Diego - Telefonía IP

Documents

Transcript of Abel Diego - Telefonía IP