Voice over Internet Protocol and Internet Telephony - Aalto file1 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi Voice over Internet Protocol and Internet Telephony Pekka Pessi

1 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi

Voice over Internet Protocol andInternet Telephony

Pekka PessiNetworking Technologies Laboratory

Nokia Research Center


Contents

• RTP/RTCP, Packetizing voice and video, codecs

• Voice over IP

• Codec features

• Wireless

• QoS

• Internet Telephony:

• H.323

• SIP and SDP

• ENUM, TRIP, CPL, etc.

• Media Streaming, RTSP


RTP - Real-Time Transport Protocol

• RTP/RTCP specified in RFC 3550 (Internet Standard 64)• Provides means for application to restore packet sequence and

timing:• sequence number, timestamp, source identifier

• Runs on top of any transport protocol• UDP, TCP, AAL5• "Real-time" does not mean "fast"

• Lightweight, designed according ALF, ILP• Application integrated with RTP implementation

• Designed for multicast• "unicast is special case of multicast"


RTP Packet

V P X CC M PT Sequence numberTimestamp

Synchronization Source Identifier (SSRC)

Contributing Source Identifiers (CSRC)

Extension Identifier Extension Length

RTP Header Extension

RTP Payload

Pad lengthPad

If X ≠ 0

If P ≠ 0

If CC ≠ 0

12 bytes


Putting Speech into Packets

Sender:

• A/D conversion

• Collecting samples into a frame

• Coding or compressing frame

• Sending frame(s) within a packet

Receiver:

• Reordering and synchronizing packets

• Decoding or decompressing frames

• D/A conversion

F r a m e F r a m e

A

t S a m p l i n g

Qua

ntiz

atio

n


Video in Packets

• Video is stream of pictures

• Picture divided into blocks

• Blocks encoded using discrete cosine transform (like JPEG)

• INTRA/INTER mode:

• INTRA mode: encodecomplete picture

• INTER mode: encode differences between pictures

• Motion prediction

81 01 2

79

1 1

246

135

1

3 3

2 3 4 5 6 7 8 9 1 0 1 1

1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2

2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1 3 2

Time

P i c t u r e

G O B

M a c r o b l o c k

L u m i n a n c e b l o c k s

C o l o u r b l o c k s


RTP in Action

0 10 1 0

0 20 3 0

0 30 7 0

0 40 9 0

0 51 1 0

0 61 3 0

0 71 5 0

0 10 1 0

0 20 3 0

0 30 7 0

0 40 9 0

0 51 1 0

0 61 3 0

0 71 5 0

S E QT S

R e c e i v e r

S e n d e r01

0

030

050

070

090

110

130

150

010

030

050

070

090

110

130

150

170

190

S E QT S


RTCP - Real-Time Control Protocol

• Designed for loosely coupled multimedia multicast session• Packet types: SR, RR, SDES, BYE, APP • SR: Sender report, RR: receiver report

• Means for congestion control, calculating packet loss, jitter• Synchronization between streams

• SDES: Source description• BYE: Participant is departing conference• APP: Application-specific packets• Extended packet types:

• RTPFB, PSFB (feedback)• XR (more detailed receiver reports, RFC 3611)


RTP Profiles

• RTP profile defines guidelines for• timestamp rate, packetization, marker bit usage• extensions to RTP header

• STD 0065 - RFC 3551 - RTP Profile for Audio and Video Conferences with Minimal Control (“RTP/AVP”)

• Audio profile, video profile

• Contains packetization for many codecs:PCMA (G.711A), PCMU (G.711µ), GSM (GSM 06.10 FR), G.729, G.723, ADPCM (G.726), L8, L16, DVI4, G.722, G.728, H.261, nv


Audio Profile for RTP • M bit is used to mark start of speech burst

• Sampling frequency used as timestamp frequency

• Timestamp indicates sampling time of oldest sample

• Frame-based codec guidelines:

• 1..N speech frames in each RTP packet

• frames typically octet padded, concatenated

• frames from all channels consecutive, fixed order, all channels in same packet


Video Profile for RTP• M bit indicates last RTP packet in frame

• 90 kHz timestamp frequency

• nice multiple of 25 Hz, 24 Hz, 29.97 Hz, 30 Hz

• mainly because simple frame/field rate is insufficient for RTCP jitter calculation

• Frame can be split into multiple RTP packets

• All packets have same timestamp, different sequence number

• Some audio codecs may use video profile (MPA or MPEG audio)


SRTP - Secure RTP Profile• Usual Internet security protocols unusable with RTP

• TLS did not work with UDP

• IPSec prevents header compression, no unequal error protection, uses block ciphers (bit errors spread)

• Solution: SRTP (RFC 3711)

• Confidentiality, authentication, replay protection for RTP/RTCP

• Defined as a special RTP profile

• Stream cipher for payload only• keystream generated by AES in counter mode, or f8 mode

• Optional authentication with HMAC-SHA1


RTP Summary

• RTP solves some problems of real-time media transport

• Restoring timing, reordering

• RTP designed for multicast

• RTP does not address

• QoS (packet loss, delay, network congestion)


RTP Applications: VoIP


Two Kinds of Real-Time Multimedia

• Conversational ~ VoIP ~ SIP• Telephony• Delay is critical• HiFi quality is not important

(3.4 kHz speech, 300 b/w pixels in video)

• Unidirectional ~ Streaming ~ RTSP• Radio, television• Delay is not important

(can be up to ~5 seconds, even more in multicast)• Emphasis on media quality (compared to CD, HDTV)


Why to Use IP with Voice?

• Reduce overhead• Speech coding (compression)• Silence compression

• Utilize common network technology• No more special network/connection for voice or multimedia

• Enable new kind of services• Multimedia, multicast, integrating with Internet services• High-quality voice

• Optimize rout(e)ing• Media is not tied to signaling path


Factors in End-to-End Quality of VoIP

• Voice codecs (2 kb/s ... 1500 kb/s)• Speech and audio codecs• Different algorithms:

• PCM, ADPCM, RP-LPT, LELP, CELP, jne.• Lower bitrate

=> lower speech quality, more MIPS, longer delay• Delay (conversational: ...140 ms … 400 ms)

• algorithmic, coding, packetization• network• synchronization, decoding

• Packet erasure rate (...2% … 20 %)• lost in network or dropped due to excessive delay


Voice Codec is Always Compromise• Low bitrate v. low complexity

• Audio quality v. low bitrate

• Packet loss sensitivity v. delay and low bitrate

• Delay v. packet loss

• Delay v. header overhead

• Few codecs designed with Internet in mind:

• ILBC

• AMR (3GPP)


Header Overhead

A M R1 0 . 2

1 1 . 2 2 8

R T P

1 6 . 0

1 2

U D P

1 9 . 2

8

I P

2 7 . 2

2 0

P P P

2 8 . 8

4

• RTP payload headers,RTP/UDP/IP/LL headers

• Example 1: AMR 10.2 kb/s mode on PPP• 50 frames/s, 25.5 octets/frame• RTP payload headers 2.5 octets,

RTP 12, UDP 8, IP 20, PPP 4-5• Total bandwidth: 28.8 kb/s

• Example 2: G.723.1 5.6 kb/s over ADSL

• 30 ms/frame, 21 octets/frameRTP 12, UDP 8, IP 20, Ethernet 14,SNAP 10, AAL-5 8, (pad 3), ATM 10

• Total bandwidth: 28.3 kb/s


… and more

• + RTP + UDP + IPSEC + Mobile IP+ IPv6 + IEEE802.3 + LLC-SNAP + AAL5+ ATM ...

• More than 80% of packet is headers

• Putting more frames in one packet• multiplies packetization delay• worsen packet loss degradation

(multiple frames lost at once)

• CRTP or ROHC reduces header overhead to 2..4 octets in the best case

• (…but not with IPSEC)

5 6 . 0

A M R1 0 . 2

R T P

U D P

I P v 6

H A o p t i o n( M o b i l e I P v 6 )

E H( I P S E C )

E t h e r n e t

1 4 0


Delay Budget

• Example:AMR 12.2 codec, 2 frames in packet (speech 64, total 104 octets),64 kb/s ISDN, inter-continental link and 256 kb/s ADSL

• Algorithmic 25 ms Encoding 5 msPacketization 20 msNetwork (ISDN) 14 ms (6 ms because of headers)Network (Core) 80 ms .. 100 msNetwork (ADSL) 4 ms (3 ms because of headers)Synchronization 20 ms .. 40 msDecoding + 2 msTotal 190 ms


VoIP on Wireless Networks

• Wireless links differ from wireline• Lot of bit errors (1E-3 — 1E-4)

• Error correction codes (e.g., convolution coding) at link layer• Forward Error Correction (FEC) at application layer

• Bandwidth varies• Bad reception requires more error correction, leaving less

bandwidth for data• Solution: codecs with variable bit rates (AMR)

• Really narrowband links• Error rate causes problem for normal header compression• Solution:

RObust Header Compression (ROHC) orCompressed RTP (CRTP)


UDP Lite

• Usually in Internet, one bit error causes packet loss

• But media codecs tolerate bit errors better than packet loss

• Solution:

• UDP Lite (RFC 3828)

• Use unequal error protection, ignore some bit errors

S p e e c hR T PU D PI P

U D P L i t e C h e c k s u mC o v e r a g e

U D P C h e c k s u mC o v e r a g e


VoIP and Network Performance

• Processing, queueing, propagation delay• VoIP has large packet overhead

• "Lot of little packets full of headers"• high number of packets increase load on routers, longer

processing delay• header overhead causes relatively long propagation delay

• Real-time queueing:• by-pass long queue, use short RT-specific queue • packets may be lost already on low load• RT-load must be much lower than non-RT load

• IntServ (RSVP)• DiffServ• MPLS


VoIP Myths• VoIP saves bandwidth

• ...if you don't count header overhead

• VoIP quality is hopeless compared to PSTN

• ...only if you are happy with 3.4 kHz PSTN quality

• VoIP is useless without QoS in whole Internet

• ...in core Internet, jitter is less than 1 ms

• VoIP is free

• ...only almost


Other RTP Applications

• Conferencing - SAP (RFC 2974)

• Session source multicasts SDP session description

• No negotiation - take it or leave it

• Streaming - RTSP (RFC 2326)

• Client asks server for session description

• URL addressing, HTTP-like transaction model

• Media and codec negotiation by RTSP URLs

• Multiple streams

• Firewall/NAT-friendly (RTP tunneling)

• Distributed content servers


Internet Telephony


Two Standards for IP Telephony

• H.323 from ITU-T

• H.323v5 approved in May 2003

• SIP from IETF

• RFC 3261 (“SIP/2.0bis”)published in June 2002


H.323 Suite from ITU-T

• Based on Q.931, H.320, H.324

• Umbrella specification: H.323, H.225.0, H.245

• "Videophone over TCP/IP LAN"

• Follows classic telephony model

• Binary encoding (Q.931, ASN.1/PER)

• Predefined services(H.450 series services, defined using X.880 RPC)

• Lot of baggage

• Designed by a committee

• Too complex (total 808 pages) but still missing features


H.323 Components

P S T N

G a t e w a yG a t e k e e p e r

T e r m i n a l s

I P

M C U

M P

M C

• Entities:terminal,gateway,gatekeeper


Basic H.323 Protocol Stack

IP

UDP

RTP/RTCP

RTP/RTCP

AudioCodec

RAS

TCP

X.224 (RFC 1006)

H.245Q.931

T.122

T.120Video

Codec

H.323 Videophone Application


T.120 Multimedia Conferencing

• ITU-T protocol suite for multiparty conferencing

• Application sharing (T.128)

• Whiteboarding (T.126)

• Text chat (T.134, T.140)

• File sharing (T.127)

• Transport-independent

• Modem, ISDN, Internet (T.123)

• Uses its own multipoint servers (T.125)

• E.g., Microsoft Netmeeting, Windows Messenger


SIP from IETF

• Based on SAP, RTSP, HTTP

• Multicast multimedia conferencing

• Original scope was inviting individuals to multicast conferences (Session Invitation Protocol)

• Evolved to set up unicast and person-to-person calls(Session Initiation Protocol)

• "HTTP over UDP"

• Base specifications in RFC3261, RFC3262, RFC3263, RFC3264

• Simple, lightweight, flexible

• RFC 3261 is largest RFC ever published, 269 pages

• Total SIP/SDP = 370 pages


...Not so Simple Anymore RFC 3261 SIPRFC 3262 100rel and PRACK methodRFC 3263 Locating SIP ServersRFC 3264 SDP Offer-Answer ModelRFC 3265 SIP Events (SUBSCRIBE/NOTIFY)RFC 2327 SDPRFC 3266 IPv6 for SDPRFC 2976 INFO methodRFC 3311 UPDATE methodRFC 3312 PreconditionsRFC 3323 Privacy extensionRFC 3325 P-Asserted-IDRFC 3326 Reason headerRFC 3327 Path extensionRFC 3329 Security AgreementRFC 3420 message/sipfragRFC 3428 MESSAGE methodRFC 3515 REFER methodRFC 3581 rport

RFC 3608 Service-Route headerRFC 3903 PUBLISHRFC 2617 Digest authenticationRFC 2782 DNS SRV, RFC 2915 NAPTRRFC 3050 CGI for SIP RFC 3320 SigCompRFC 3486 Compressing SIPRFC 3485 SIP/SDP SigComp Dictionary RFC 3840, 3841 Caller preferencesRFC 3856 SIP PresenceRFC 3859 Common Presence Profile (CPP)RFC 3863 PIDFRFC 3857, 3858 WatcherinfoRFC 3880 Call Processing Language (CPL)draft-ietf-simple-event-lists-07draft-ietf-simple-xcap-07draft-ietf-sip-session-timer-15draft-sparks-sip-nit-actions-03...


SIP in Nutshell

• Modelled after HTTP/1.1:

• Addressing using URLs

• Plain text headers, allows very simple "miniservers"

• Transaction-based (request-response), redirections

• Authentication model

• Differences from HTTP:

• Built-in personal mobility (“rendezvous service”)

• Services implemented mostly by proxies

• Request forking, real-time requests (timeout after 32 sec)

• Transport-independent: UDP, TCP, TLS, SCTP


SIP MessageINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP kton.bell-tel.comFrom: A. Bell <sip:[email protected]>To: T. Watson <sip:[email protected]>Call-ID: [email protected]: 1 INVITESubject: Mr. Watson, come here.Content-Type: application/sdpContent-Length: 130

v=0o=bell 53655765 2353687637 IN IP4 128.3.4.5s=Mr. Watson, come here.c=IN IP4 kton.bell-tel.comm=audio 3456 RTP/AVP 0 3 4 5

SIP Headers

SDP MediaDescription

as SIP Payload

Request method

RequestURI


SIP Transactions

• SIP transaction consist of

• a request message sent by client to server,

• optionally followed by provisional response message from server to client, and

• a final response message from server to client

• (in case of INVITE)an ACK message from client to server

SIP ServerSIP Client

INVITE

100 Trying

180 Ringing

200 OK

ACK


SIP Requests

• Transaction requests

• INVITE - call setup (also hold, resume, transfer, ...)involves user interaction (no timeout if provisional response has been received, indefinite duration)

• BYE - call release

• OPTIONS - query UA capabilities and/or status

• REGISTER – update user contact information

• Other requests

• CANCEL - aborting (INVITE) transaction

• ACK - acknowledge final response to INVITE


SIP and SDP

• SIP uses SDP (RFC2327) to describe sessions

• SDP is transmitted as payload of SIP call setup messages

• IP addresses, port numbers, codec types, packetization, etc., for each media

• Media negotiation with SDP Offer/Answer Model (RFC3264)

• SDP is very simple

• full implementation < 2 kLoC (H.245 is ~ 100 kLoC)

• allows selecting audio and/or video codecs

• but selecting individual codec modes is hard

• may be replaced in future with, e.g., XML-based solution


SIP Entities• SIP Entities:

• user agents

• proxies

• registrars

• redirect servers

• back-to-back user agents


SIP User Agents

User Agent (UA)

• Consists of a client and a server

• Examples: Terminal, MCU, Gateway

• User Agent Client (UAC):• Initiates SIP transactions

(sends requests)

• User Agent Server (UAS):• Accepts SIP transactions

(receives requests and acts on them)

• Both server and client functionality required during a call!


SIP Proxies

Stateless proxy• forwards SIP messages• does not maintain transaction nor call state scalable

Stateful proxy• forwards SIP transaction - keeps transaction state• acts as server to one direction and as client to another• can fork requests: incoming SIP request may create several

virtual clients, each executing a transaction, the combined result is returned back to the original client


SIP Redirect and Registrar Servers

Redirect Server• accepts request and returns a list of addresses to the client• very simple implementation

• needs to understand two headers• scalable

• no need for transaction state• never maintains call state

Registrar Server• server accepting REGISTER transactions• updates location database• usually co-located with proxy/redirect server


Back-to-Back User-Agent• SIP limits the operations a proxy can perform

• Intermediate element not behaving by proxy rules is B2BUA

• B2BUA can modify session description, authentication and identification info, etc

• Problematic because they break end-to-end connectivity and transparency

• Applications:

• Session border controller, application-level gateway, transcoder


SIP Call Example

sip.nokia.com sipgw6.nokia.com

sipgw7.nokia.com

sipgw8.nokia.com

sipgw9.nokia.

sipgw10.nokia.com

location.research.nokia.com

pc-pessi.research.nokia.compessi.koti.sonera.fi

labra-pc-18.research.nokia.com

(1) INVITE

[email protected]

(2) [email protected]

(3) 100 Trying

(4) INVITE

[email protected]

(5) 302Found

(6)INVITE (6)

INVITE

(6) INV

ITE

(8) 180Ringing

(7) 480

Not available

(7) 180 Ringing

(7) 180R

ingi ng(9) 200 O

k

(10) 200 Ok

(11)ACK

(12) AC

KMEDIA

alice.wonderland.org

(10)CANCEL

(8)A

CK


SIP Instant Messaging and Presence (SIMPLE)

• Instant messages (like SMS or MMS)

• Uses MESSAGE method (RFC3428)

• MIME payload, CPIM wrapper

• Maximum size 1300 bytes

• Presence

• Uses SUBSCRIBE/NOTIFY (RFC3265) and PUBLISH (RFC 3903)

• Basic presence (CPIM) indicates if user is willing to receive instant messages

• Extensions proposed for other modes of communication, device capabilities, user activity, location, mood, future availability


SIP Security

• Digest authentication (from HTTP)

• Based on shared secret (password or a key from SIM)

• SIPS URI scheme (just like HTTPS)

• Uses TLS (or equivalent) as transport

• Clumsy with UAs (a certificate required for all devices)

• S/MIME (from e-mail)

• End-to-end security for message payload

• Using self-certified certificates if no PKI available

• Used also to secure authentication tokens(hop-by-hop security)


Locating SIP Users and Services

• SIP uses URIs for addresses:

• sip:[email protected]

• im:[email protected]

• tel:+358718036404

• URLs are mapped to IP addresses using DNS

• SIP/SIPS URIs using RFC3263 (NAPTR, SRV, AAAA/A)• Provides load balancing, transport selection,

switchover after failure

• ENUM

• Gateways to PSTN can be located with TRIP


ENUM

• Protocol for mapping telephone numbers into URLs

• Mapping based on service required

• Using DNS NAPTR

• RFC 2916

• E.g., calling to +358 71 800 8000:

• Converted to domain name0.0.0.8.0.0.8.1.7.8.5.3.e164.arpa.

• 0.8.1.7.8.5.3.e164.arpa. resolves to NAPTR 10 10 "U" "SIP+E2U" "!+(.*)!sip:+\[email protected]!” .

• Telephone number is matched to regexp, and resulting URL is used to place the call


TRIP

• Inter-domain call routing protocol

• Based on BGP

• Locates suitable destination for a telephone number

• Protocol-independent

• Supports booth H.323, SIP

• Routing based on policy

• Cost, quality, reliability, features


Creating SIP Services

• SIP services can be built like WWW services

• CGI scripts, servlets, miniservers

• Services are created within SIP proxy network

• No special IN servers or protocols – SIP can always be used

• Presence-based and location-based services

• SIP-specific:

• Callee capabilities, caller preferences

• Call Processing Language (CPL)

• KPML (keypress markup language) for IVR applications

• Events (presence, call status, conference status)


Callee Capabilities and Caller Preferences• Callee can specify different contacts:

• audio, video, chat, mobile, business phone, voicemail

• Caller can ask for specific services:

• video, mobile, business phone, no voicemail

• Caller can ask how a request is processed:

• proxying, redirecting, forking, recursive


CPL - Call Processing Language

• XML-based rules for processing and routing calls• Robust, safe, suitable for large-scale servers<cpl> <subaction id="voicemail"> <location url="sip:[email protected]"> <redirect /> </location> </subaction> <incoming> <location url="sip:[email protected]"> <proxy timeout="8"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <address-switch field="origin"> <address is="sip:[email protected]"> <location url="tel:+19175551212"> <proxy /> </location> </address> <otherwise><sub ref="voicemail" /></otherwise> </address-switch> </noanswer> </proxy> </location> </incoming></cpl>


Problems with Internet Telephony

• No more end-to-end connectivity on Internet

• Firewalls, NATs work with client-server only

• Internet is no more suitable for peer-to-peer applications

• Solutions:• IPv6• Application-level gateways (ALGs)• STUN/TURN/ICE• UPnP

• Security models require central authority

• PKI or operator


SIP and 3G

• 3GPP release 5 and 6

• New subsystem called IMS(IP Multimedia Core Network Subsystem)

• TS 23.228, TS 24.229

• Adds network elements likeP-CSCF, I-CSCF, S-CSCF, MRCF, MRPF

• SIP Proxies, RTP media processors, etc.

• Internet multimedia calls signaled using SIP

• Messaging and Presence

• Streaming using RTSP

• 3GPP2 adopts IMS, too


Internet Telephony

RTP RTCPAMR H.263 MPEG

RSVP UDP Lite ROHC

SIP SDPSIMPLE

ENUM URIs E1.64 DNS TRIP CPL CGI Servlets

CPIM

Presence ReachabilityInstant multimedia messaging

Push-to-talk Click-to-dial Chat-to-callMultimedia conferences

Voice and video mailboxes

Voice over Internet Protocol and Internet Telephony - Aalto file1 Tik-110.350 Tietoverkot / 27.4.2005 / Pekka Pessi Voice over Internet Protocol and Internet Telephony Pekka Pessi

Documents