20051118 voip standards - hsrm2005/11/18 · 20051118 voip standards cisco public end-to-end ip qos...

Copyright © 2005, Cisco Systems, Inc. All rights reserved. Printed in USA.

20051118 VoIP Standards

1© 2005 Cisco Systems, Inc. All rights reserved. Cisco Public20051118 VoIP

Standards

VoIPStandards and Status

Johannes Krohn ([email protected])

2© 2005 Cisco Systems, Inc. All rights reserved.20051118 VoIP

Standards Cisco Public

Agenda

• Voice transport over IP

• Signalling Protocol Classification

• IETF Overview

• VoIP signalling protocols

H.323

MGCP

SCCP

SIP

• Myths / Facts





Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts



Voice Packetization

DSPG.711

Analog Digital

(Predigitized)

Compressed Packetized

L3 L2

Reverse Process

Packet Transport

ATM or IP

Sampling (PAM)

Companding (A-Law, Mu-Law)

PCM Coding (PCM G.711)

G.726 ADPCM

G.728 LD-CELP

G.729(AB) CS-ACELP

G.723.1 ACELP/MPMLQ

VoIP (ovL2)

VoATM

(VoFR)





Voice Encapsulation over IP

• Designed to carry real-time traffic on top of IP

• Real-Time Protocol (RTP)—media

• Real-Time Transport Control Protocol (RTCP)—form of signaling between RTP termination points

Watches the quality of underlying infrastructure

• RFC1889 and 1890

RTP

RTCP

Voice Payload RTP UDP IP

Variable 12 8 20

L2

Cisco IOS® RTP UDP Port Range=

Four Ports Dynamically Allocated per Single

Full-Duplex CallEven-Numbered Ports

Odd-Numbered Ports

Routing/Addressing

Ports Multiplexing/(CRC)

Sequence Numbers

Payload Type Identification

Timestamps

IP Network

Cisco IOS Voice Gateway

Cisco IOS Voice Gateway



Voice QoS Network Requirements

• Low delay

Long delays cause the listener to start to talk before the speaker is finished

• Low delay variation (jitter)

Jitter causes gaps in the speech pattern that cause the quality of voice to sound “jerky”

• Low packet loss

Packet loss causes voice to sound “jerky” and annoying

• Low echo

Listener annoyed by hearing the speaker twice phase-shifted





Differentiated Services Architecture(RFC 2274, RFC 2275)

Ingress Interior Egress

Complex Traffic Classification

and Conditioning (TCB)

Classification/Marking/Policing

Simple PHB on

Traffic Aggregates

Scheduling/Congestion Avoidance

No Perflow StateTraffic Classes Provisioning

IP/DS Domain



TTLOffsetIDLenToSByte

DataIPDAIP SAFCSProtoVersionLength

Flow Clontrol

DSCP

UnusedIP Precedence

23456 017

Encoding Traffic Classes (DSCP)

• DiffServ field: the IP version four-header ToS octet or the IP version six traffic-class octet when interpreted in conformance with the definition given in RFC2474

• DSCP: the first six bits of the DiffServ field, used to select a PHB (forwarding and queuing method)

IPv4 Packet

IPv4 IP Precedence

DS Field





Per-Hop Behaviors (PHB)

• Expedited Forwarding (EF)

Building block for low delay/jitter/loss (voice/video)

Served at a certain rate with short/empty queues

• Assured Forwarding (AF)

Designed for data

High probability of delivery if profile is not exceeded

Four classes and three levels of drop precedence

Specific resources (BW, buffer space) allocated to each class at each node

• Best Effort (BE)



End-to-End IP QoS for Voice Delay Mechanisms

• Delay is a problem for us/humans, not the technology

• G.114 recommends less than 150-ms end-to-end, one-way delay

• Points of congestion are more susceptible to build delay

• Multiple-delay types

Codec-algorithmic, processing, serialization, propagation

EF PHB

Priority Queuing

(LLQ/IP RTP Priority, MDRR)

Priority Queuing (LLQ/IP RTP Priority)

Link Fragmentation and Interleaving (Serialization on Slow Links)

cRTP (Smaller Packets get Through Faster)

SP (DS)

Customer Customer





End-to-End IP QoS for Voice Delay Variation Mechanisms

• Delay variation causes buffer underruns → codec desynchronization

• Occurs due to mixing traffic of different types from different sources

• Different traffic types meet in output buffers

• Points of congestion are more susceptible to introduce delay variation

vvvvv v v vvvvv

Adaptive Buffer

DSP

“Jittered” Stream

SP (DS)

Customer CustomerEF PHB

Link Fragmentation and Interleaving (Small Packets Interleaved)



End-to-End IP QoS for Voice Packet Loss Mechanisms

• Voice can survive some packet loss—how much depends on codec

• Points of congestion drop packets due to buffer overflow

• Voice stream is not adaptive (UDP), does not react to WRED

SP (DS)

Customer CustomerEF PHB

Queuing (Guaranteed BW)(LLQ/IP RTP Priority, MDRR)

“Protecting” Real-Time (WRED on Data)

Classification + Policing (CB-Policing/CAR)

Call Admission Control/RSVPQueuing (Guaranteed BW with LLQ/IP RTP Priority)Bandwidth Efficiency Mechanisms (cRTP)





Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts



Protocol Architecture Models

Traditional

SCCP, MGCP

H.323, SIP

Terminal

MGC

Peer

Client

Host

Peer

Server

• Terminals are managed by the switch/host and cannot talk directly to other terminals

• Peer endpoints can place calls without the presence of a call agent, but may consult call agents/proxies for name resolution/redirection

• Client endpoints cannot initiate calls without their call agent, but media streams flow peer to peer





Distributed Call Control: H.323 and SIP

• All signaling messages and dialed digits are interpreted by the protocol stack on the Endpoint/Gateway

Gateway/Endpoint is an “intelligent”device

• Peer-to-peer call setup (dial plan/IP address servers are optional)

If IP Address Server is out of reach, the Endpoint/GW can choose an alternate route

• TDM signaling types supported is a function of the GW protocol stack

• Resilient over IP connectivity failures

• Scalable – distributed CPU power

• New applications deployed where needed w/o affecting rest of the network components (Internet model)

• Distributed configuration

GK

GW

H.323

Endpoint

IP

PSTN

SIP

PS

SIP

Endpoint

H.323 or

SIP GW

Optional signaling to locate IP address of peer

Call setup signaling

Media

IP Address

Servers



Distributed Call Processing

Call Setup11

E.164 Lookup22

Call Setup33

Ringback88E.164 Lookup44

Call Setup55

Alerting77

Call Connect1010

Connect RTP Stream1111

Ring66

IP WAN11

22

33

88

44

55

77

1010

1111

6699

Off Hook99





Centralized Call Control: MGCP and SCCP

• All signaling messages are “back-hauled” to the Call Agent

Gateway/Endpoint is a “dumb” device

• Call Agent arbitrates all call setup

If Call Agent is out of reach, the Endpoint/GW cannot function

• TDM signaling types supported is a function of the GW and Call Agent

• Dependent on IP network connectivity

Requires failover strategies

• Scalable – central Call Agent is a contention point

• New applications deployed requires Call Agent upgrade (CO model)

• Centralized configuration

GW

IP

PSTN

SCCP

SCCP

Endpoint

MGCP GW

Call setup signaling

Media

Central Call

Agent



Centralized Call Processing

CiscoCallManager

IP

WAN

Ring Back44

44

Call Setup33

33

E.164 Lookup22

22

Call Setup11

11

Off Hook66

66

Connect RTP Stream77

77

Ring55

55

Centralized Call Processing





Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts



IETF Standards Process

• SIP has an RFC number assigned to it [3261], it’s a “Standard” right?

• Let’s examine the IETF Document Process

• 6 Classes of documents– Standards Track

– Best Current Practice (BCP) - 1 shot Standard

– Informational - not intended to Standardized

– Experimental - not sufficiently studied to Standardize

– Historical - not to be coded to anymore

– Obsoleted - revised by another RFC





IETF Standards Process (Cont.)

• Best Current Practice – 3 stage process– Most often references other RFCs and

Standards to put an “Architecture” together

– Or, could state what “shouldn’t be done”

– Doesn’t generally have new feature

descriptions (called “normative text”)

There are 2 Categories of Standards in the IETF:

• Standards Track – 5 stage process




Standards Track Documents

• 5 Document levels (called a “Status”)

– First: the Individual “Internet Draft”• Can be written by anybody, or asked for by a WG Chair(s),

or can be the result of a “Design Team” collaboration

• ASCII Formatted only

• Valid for up to 6 months (with an electronic cutoff)

• Can be revised/renewed (theoretically indefinitely)

• Must become an Official Working Group Item at some point

• WG Chair submits a version to the WG as WGLC for “consensus”

• WG Chair submits WG consensus ID to IESG for RFC

“acceptance”

• Assigned an RFC number and published

• It’s now a Standard, right?






Standards Track Documents (cont’d)• Proposed Standard (PS)

– Core of this stage is the “Request for Comments” aspect

– 18 months to 2 years here (best case... usually 3-5 yrs)

– “MUST” have two independent interoperable “completely” compliant implementations demonstrated to IESG to become DS

• Draft Standard (DS)– Considered “worthy” for Standardization

• Generally should have a 3rd implementation to become FS

• Standard (FS or just STD)– Only 62 of these exist !

But there are more than 3825 RFCs... How does that work?!




Which Category are these Protocols/Apps in?

RADIUS

HTTP/1.1

IPv6

DHCP

MIME

BGP-4

BOOTP

RTP

SIP

MGCP

IPv4

ICMP

UDP

TCP

Telnet

FTP

TFTP

SNMPv3

ARP

DNS

PPP

POP3

OSPFv2

RIPv2

RSVP

IPsec

GRE

Diffserv-EF

Diffserv-AF

LDAPv3

TLS

IMAPv4

MPLS

IKE

COPS

CIDR

SDP

L2TP

SMTP

DVMRP





March 2003 -- SNMPv3 to Full STD



RADIUS

HTTP/1.1

IPv6

DHCP

MIME

BGP-4

BOOTP

RTP

RSVP

IPsec

GRE

Diffserv-EF

Diffserv-AF

LDAPv3

TLS

IMAPv4

ARP

DNS

PPP

POP3

OSPFv2

RIPv2

MPLS

IKE

COPS

CIDR

SDP

L2TP

SMTP

DVMRP

Standard

SIP

MGCP

IPv4

ICMP

UDP

TCP

Telnet

FTP

TFTP

SNMPv3



Standard Draft Standard



RADIUS

HTTP/1.1

IPv6

DHCP

MIME

BGP-4

BOOTP

RTP

ARP

DNS

PPP

POP3

OSPFv2

RIPv2

Proposed Standard*

SIP

IPv4

ICMP

UDP

TCP

Telnet

FTP

TFTP

SNMPv3

RSVP

IPsec

GRE

Diffserv-EF

Diffserv-AF

LDAPv3

TLS

IMAPv4

MPLS

IKE

COPS

CIDR

SDP

L2TP

SMTP

*No Protocol Extensions can progress until ALL normative references have progressed





Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts



H.323 Background

• International (ITU) standard for:

Packet-based multimedia communications systems

• Originated from H.320 (multimedia over ISDN)

• ITU recommendation

v1 approved in 1996, v2 in January 1998, v3 in September 1999,

v4 in November 2000, and v5 in July 2003

• Leverages existing standards, i.e., H.320, Q.931, H.450, etc.

• Wide market acceptance

• Facilitates interoperability between vendors





H.323 Components

• ITU Standard

• Terminal—Endpoint

• Gateway (GW)—TDM to IP conversion

• Gatekeeper (GK)—Phone number and name to IP address lookup and CAC bandwidth management

• Directory Gatekeeper (D-GK)—Tiered hierarchy of GKs

• MCU—Multipoint Control Unit to mix audio and replicate video

GK GK

H.323

Terminals

H.320 Terminal

(ISDN)

H.324 Terminal

(POTS)

GW GW

H.323

Terminals

MCU

D-GK

IPZone1 Zone2

PSTN



Scope of H.323 Recommendation

Video CodecH.261, H.263

Call Control

H.225.0

System Control

Receive

Path

Delay

(Sync)Audio Codec

G.711, G.722,

G.723, G.728,

G.729

RAS ControlH.225.0

UDP

H.245 Control

H.225

Layer

RTP

RTCP

TCP

UDP

IP

Audio I/O

Equipment

User Data

Applications

T.120

System Control

User Interface

Video I/O

Equipment





H.323 Endpoint-to-Endpoint Call Setup

• H.225 Messages (Signaling Protocol) is based on Q.931

Connect

Assumes endpoints (clients)

know each other’s IP Addresses

H.323 Gateway H.323 Gateway

Logical Channel Set-Up (RTP/RTCP)

Logical Channel Set-Up (RTP/RTCP)

Media (UDP)

Bearer

Plane

Bearer

Plane

Set-Up H.225

Signaling

(TCP)

Signaling

Plane

Signaling

Plane

H.245

Signaling

(TCP)

Capabilities Exchange



IPZone1 Zone2

H.323 Call Setup with Gatekeeper (GK)

GK GK

RRQ

RCF

ARQLRQ

RRQ

RCF

LCFACF

ARQ

ACF

H.225.0 Setup

DRQ

DCF

Active CallDRQ

DCF

H.225.0 Connect with H.245 Capabilities

GWGW

Assumes endpoints don’t

know each other’s IP Address

IP address of the terminating device is

returned by GK to the originating

device





Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts



Background - Media Gateway Control

SGCP(July 1998)

MGCP 0.1(Nov 1998)

• And then it was proposed to the IETF and ITU, and...





IPDC

MDCP

H.GCP

SGCP

MGCP

MxCP?

ITU-T SG 16IETF MEGACO

Background - Between 11/98 and 3/99



Background - Media Gateway Control

SGCP(July 1998)

MGCP 0.1(Nov 1998)

MGCP 1.0RFC 3435

(Jan 2003)

MGCP 1.0RFC 2705

(Oct 1999)ISC

• International SoftSwitch Consortium (ISC) continued with MGCP: development, extensions, Interop testing

H.248 V1(March 2002)

H.248 V2(May 2002) ITU/ (IETF)

H.248 V0(June 2000)

• ITU/IETF H.248 work was initiated at a point when initial MGCP development was fairly complete

• Both Use Session Description Protocol (SDP, RFC 2327) to describe media capabilities - Just as SIP does





MGCP Concept

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

RFC3435



Media Gateway Controller(Call Agent)

MGCP

IP PSTN

ISUP SS7 GW

SS7SS7

PRIPRIPRIPRI

DSLDSL

MGCP—Components

MGC

TMG

RMG

AMG

Trunking Gateway (TMG): interfaces

SS7 bearer channels to IP network

Access Gateway (AMG): interfaces PBX trunks to IP network

Residential Gateway (RMG): interfaces customer POTS

lines to IP network

Virtual Switch





MGCP Call Setup

MGMG

Create Connection Reply with SD

NotifyNotify Ack

Create Connection

User Information Exchange

Create Connection

Notify

Notify Ack

Create Connection Reply with SDModify Connection with returned SD

Delete Ack

Delete

Delete Ack

Delete

Release Compl

Release

Release Compl

Release

MGC



Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts





SCCP-Skinny Client Control Protocol

• Client – Server protocol

• used in Cisco Enterprise IPT solution (CallManager)

• available to external developers

• stimulus based

• no intelligence in the endpoints



AVVID SCCP Client Registration

Station Register Station Register

Station Register Ack or Rej Station Register Ack or Rej

Station Capabilities Request Station Capabilities Request

Station Capabilities Response Station Capabilities Response

Station Button Template Req Station Button Template Req

Station Button Template Res Station Button Template Res

Station Time Date Req Station Time Date Req

Station Define Time Date Station Define Time Date

DHCP Request DHCP Request

DHCP Reply w/TFTP Addr DHCP Reply with /TFTP Addr

TFTP Request for .cnf TFTP Request for .cnf

TFTP Reply with .cnf file TFTP Reply with .cnf file





AVVID SCCP Client Call Connect

Station Off-Hook

Station Keypad Button

Station Off-Hook

Station Call Info

Station Open Receive Channel

Station Display Text

Station Set Lamp (Steady)

Station Start Tone (Inside)

Station Stop ToneStation Keypad Button

Station Keypad Button Station Call Info

Station Set Lamp (Blink)

Station Set Ringer (Inside Ring)

Station Set Ringer Off

Station Set Lamp (Steady)

Station Open Receive Channel

Station Start Tone (Alerting)

Station Stop Tone

Station Call Info

Station Start Media XmissionStation Open Receive Channel Ack

Station Open Receive Channel AckStation Start Media Xmission

User Information Exchange



Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts





SIP Components

• IETF Standard (PS)

• SIP Proxy Server (PS)

Registration Server (REG) – Accepts registration requests from UAs

Redirect Server (RED) – Maps SIP request to one or more addresses

Location Server (LOC) – Provides information on a callees locations

• User Agent (UA)

SIP Gateway (SIP-GW)

IP Phones (SIP)

User Agent

2 - INVITE

3 - INVITE

4 - 3XX Redirect

5 - INVITE

6 - 200 OKAY

7 - 200 OKAY

RTP

1 - REGISTER

SIP-GW

LOC

RED

SIP

PS



Factors, that delayed SIP in the Enterprise

• SIP is relatively new, having just been published in 1999

• SIP was and is still evolving, and certain issues still need to be resolved.

• Solutions using SIP were and are generally not full featured, but rather a subset of the standard features required in enterprise networks today.

• Some offerings use SIP as an encapsulation protocol, thereby negating the interoperability and application benefits of SIP. This implementations out there are propriatary.





The Reality: SIP is Ready, SIP is Mature

• The Core SIP Specifications and many of its extensions are at an excellent level of maturity (most of what you need is DONE)

• A lot of very hard problems are solved

• This is ready to implement and folks are implementing now

• Many unpublished specifications are basically ready, but waiting for process overhead



Agenda



• IETF Overview


H.323

MGCP

SCCP

SIP

• Myths / Facts





Will SIP solve everything .... ?

• Endpoints of vendor A will operate with basicfunctionality on Vendor B`s „IP-PBX“ and viceversa.

• There will be vendor dependant extensions that will not interoperate with others.



Myths and Facts About SIP

Myth

Fact

This is the greatest misperception of SIP today. SIP defines how

user agents and servers communicate, but does not define

how to implement services

By implementing SIP, all components will be interoperable now and

in the future

Distributed, peer-to-peer protocols are superior to client-server protocols

There are advantages and disadvantages to each. In an enterprise voice system,

centralized control can be more beneficial than distributed.

Scaling is possible with different architectures; the largest VoIPnetworks in the world today use

H.323.

SIP is the only protocol that will allow scaling

SIP is expected to be a leading contributor in the development of new services, however, protocols such as XML already provide

value in enterprise IP Communications

SIP is the only Internet protocol that can drive

voice application development in the

future

Partially true. SIP is designed to work above the IP network, however, it relies heavily on

network functions such as DNS, DHCP, etc.

SIP operates completely

independent of the underlying network

SIP is the future and the whole industry is moving toward it.

SIP is growing in popularity on roadmaps, but it’s not widely

deployed. Many issues still need to be solved.





The great Voice Myth

"The Great Voice Myth" states that there is only one way to build voice networks, and that there should be only one voice protocol for each function in a packet voice network.

IP is the paradigm shift, not SIP

The ability to choose protocols is fundamental to

the value of IP Communications !!!



VoIP is about services not about protocols

The question that companies must ask is not

"Which protocol is best ?“

but

"Which services do we want to deploy and which VoIPprotocols best support those services?"





Conclusion

• Customers need vendors that are committed to support open standards within their products, and are actively developing voice strategies that consider interoperability with all VoIP protocols.

• Without this commitment, VoIP systems are in danger of becoming as proprietary as legacy voice systems.

• Customers need products that support multiple protocols. This way, if a company finds that it needs to migrate its systems or add products that support a different protocol, it will not be required to perform upgrades to the network.



Q and A