Transporting Voice by Using IP
Chapter 2
Internet Overview

A collection of networks

The private networks




The public networks



LANs, MANs, WANs
Institutions, corporations, business and government
May use various communication protocols
ISP: Internet Service Providers
Using Internet Protocol
To connect to the Internet

Using IP
Internet Telephony
2
Internet Overview

Interconnecting networks

Routers provides the connectivity
Internet Telephony
3
Overview of the IP Protocol Suite

IP



A routing protocol for the passing of data packets
Must work in cooperation with higher layer
protocols
The OSI seven-layer model


The top layer: usable information passed
The information must be



Packaged appropriately
Routed correctly
And it must traverse some physical medium
Internet Telephony
4
The IP suite and the OSI stack

TCP


Reliable, error-free, in-sequence delivery
UDP

No sequencing, no retransmission
Internet Telephony
5
Internet Standards and the Process

The Internet Society




A non-profit, non-governmental, international,
professional membership organization
Keep the Internet alive and growing
“to assure the open development, evolution, and
the use of Internet for the benefit of all people
throughout the world”
The tasks




Support the development and dissemination of Internet
standards
Support the RD related to the Internet and
internetworking
Assists developing countries
Form a liaison for Internet development
Internet Telephony
6

IAB


The Internet Architecture Board
The technical advisory group



provides overall architectural advice to IESG, IETF &
ISOC
appoints IRTF chair
Technical guidance, oversee the Internet
standards process
Internet Telephony
7

IETF, formed in 1986

Comprises a huge number of volunteers


Develop Internet standards



“We reject kings, presidents and voting. We believe in
rough consensus and running code”, Dave Clark
standards only when people use them
Detailed technical work
Working groups (>100)

avt, megaco, iptel, sip, sigtran
Internet Telephony
8

IESG,The Internet Engineering Steering
Group




Area Directors + IETF Chair
Manage the IETF’s activities
Approve an official standard
Can a standard advance?
Internet Telephony
9

IANA,The Internet Assigned Numbers Authority

Unique numbers and parameters used in Internet standards


IP addresses


mostly delegated to IP 5 regional Address registries
domain names



Be registered with the IANA
deals with top level domains (TLDs)
mostly delegated to DNS name registries
functions split with the creation of ICANN

Internet Corporation for Assigned Names and
Numbers
Internet Telephony
10

Internet Research Task Force (IRTF)
 Focused on long term problems in Internet










Anti-Spam
Crypto Forum
Delay-Tolerant Networking
End-to-End
Host Identity Protocol
Internet Measurement
IP Mobility Optimizations
Network Management
Peer-to-Peer
Routing
Internet Telephony
11
Top Level View of Organization

Internet
Society
IAB
IRTF
IASA
IANA
IANA
RFC
IESG
area
area
area
“the IETF”
Internet Telephony
12
The Internet Standards Process

The process


RFC 2026
First, Internet Draft




The early version of spec.
Can be updated, replaced, or made obsolete by
another document at any time
IETF’s Internet Drafts directory
Six-month life-time
Internet Telephony
13

RFC



Proposed standard




Request for Comments
An RFC number
A stable, complete, and well-understood spec.
Has garnered significant interest
May be required to implement for critical protocols
Draft standard



Two independently successful implementations
Interoperability be demonstrated
Requirements not met be removed
Internet Telephony
14

A standard





The IESG is satisfied
The spec. is stable and mature
Significant operational experience
A standard (STD) number
Not all RFCs are standards

Some document Best Current Practices (BCPs)


Others applicability statements


Processes, policies, or operational considerations
How a spec be used, or different specs work together
STD1 list the various RFCs
Internet Telephony
15
IPR (Patents)

RFC 2026 revised IETF IPR rules



now use standards sequence to check IPR issues



used to require “fair & non-discriminatory” licensing
some standards blocked using old process
require multiple implementations based on multiple licenses
to progress to Draft Standard or Internet Standard
but a worry about “submarine patents”
IPR working group


clear up fuzzy language in RFC 2026
produced RFC 3978 and RFC 3979
Internet Telephony
16
IPR, contd.

IETF IPR (patent) rules in RFC 3979



require disclosure of your own IPR in your own
submissions & submissions of others
“reasonably and personally” known IPR
WG takes IPR into account when choosing
solution



RFC 3669 gives background and guidance
push from open source people for RF (royalty-free)only process
consensus to not change to mandatory RF-only
 but many WGs tend to want RF or IPR-free
Internet Telephony
17
IP

RFC 791




Amendments, RFCs 950, 919, and 920
Requirements for Internet hosts, RFCs 1122, 1123
Requirements for IP routers, RFC 1812
IP datagram


Data packet with an IP header
Best-effort protocol
Internet Telephony
18
IP Header

Version





4
Header Length
Type of Service
Total Length
Identification, Flags, and Fragment Offset



A datagram can be split into fragments
Identify data fragments
Flags



a datagram can be fragmented or not
Indicate the last fragment
TTL

A number of hops (not a number of seconds)
Internet Telephony
19

Protocol



The higher-layer protocol
TCP, 6; UDP, 17
Source and Destination IP Addresses
Internet Telephony
20
IP Routing


Based on the destination address
Routers



Can contain a range of different interfaces
Determine the best outgoing interface for a given
IP datagram
Routing table



Destination
IP route mask
the longest match
Internet Telephony
21
Populating routing tables

Issues




The correct information in the first place
Keep the information current in a dynamic environ
The best path?
Protocols




RIP, Routing Information Protocol
IGRP, Internet Gateway Routing Protocol
OSPF, Open Short Path First
BGP, Border Gateway Protocol, RFC 1771
Internet Telephony
22
TCP

TCP







In sequence, without omissions and without errors
End-to-end confirmation, packet retransmission,
Flow control
RFC 793
Break up a data stream in segments
Attach a TCP header
Sent down the stack to IP
At the destination, checks the header for errors


Send back an ack
The source retransmits if no ack within a given
period
Internet Telephony
23

The TCP header
Internet Telephony
24
The TCP Header

TCP Port Numbers



Identifying a specific instance of a given
application
A unique port number for a particular session
Well-known port numbers



IANA, 0-1023
23, telnet; 25, SMTP
Many clients and a server



TCP/IP
Source address and port number + Destination address
and port number
A socket address
Internet Telephony
25

Sequence and acknowledge numbers



Identify individual segments
Actually count data octets transmitted
A given segment with a SN of 100 and contains 150 octets
of data



The ack number will be 250
The SN of the next segment is 250
Other header fields




Data offset: header length (in 32-bit words)
URG: 1 if urgent data is included, use urgent pointer field
ACK: 1, an ACK
PSH: a push function, be delivered promptly
Internet Telephony
26




RST: reset; an error and abort a session
SYN: Synchronize; the initial messages
FIN: Finish; close a session
Window


The amount of buffer space available for receiving data
Checksum

1's complement of 1's complement sum of all 16-bit
words in the TCP header, the data, and a pseudo header
Internet Telephony
27

Urgent Pointer



An offset to the first segment after the urgent
data
Indicates the length of the urgent data
Critical information to be sent to the user
application ASAP.
Internet Telephony
28
TCP Connections


An examples
After receiving



100, 200, 300
ACK 400
Closing a connection



> FIN
< ACK, FIN
> ACK
Internet Telephony
29
UDP

UDP



Pass individual pieces of data from an application
to IP
No ACK, inherently unreliable
Applications






A quick, one-shot transmission of data, request/response
DNS
If no response, the AP retransmit the request
The AP includes a request identifier
The source port number is optional
Checksum

The header, the data and the pseudo header
Internet Telephony
30

UDP header
Internet Telephony
31
Voice over UDP, not TCP

Speech



Small packets, 10 – 40 ms
Occasional packet loss is not a catastrophe
Delay-sensitive


5 % packet loss is acceptable if evenly spaced



Resource management and reservation techniques
A managed IP network
In-sequence delivery


TCP: connection set-up, ack, retransmit → delays
Mostly yes
UDP was not designed for voice traffic
Internet Telephony
32
The Real-Time Transport Protocol

RTP: A Transport Protocol for Real-Time
Applications




UDP


RFC 1889
RTP – Real-Time Transport Protocol
RTCP – RTP Control Protocol
Packets may be lost or out-of-sequence
RTP over UDP



A sequence number
A time stamp for synchronized play-out
Does not solve the problems; simply provides
additional information
Internet Telephony
33

RTCP





A companion protocol
Exchange messages between session users
# of lost packets, delay and inter-arrival jitter
Quality feedback
RTCP is implicitly open when an RTP session is
open


Not mandatory
E.g., RTP/RTCP uses UDP port 5004/5005
Internet Telephony
34
RTP Payload Formats

RTP carries the actual digitally encoded voice



RTP header + a payload of voice samples
UDP and IP headers are attached
Many voice- and video-coding standards

A payload type identifier in the RTP header




Specified in RFC 1890
New coding schemes have become available
See table 2-1
A sender has no idea what coding schemes a
receiver could handle
Internet Telephony
35

Separate signaling systems



Capability negotiation during the call setup
SIP and SDP
A dynamic payload type may be used


Also support new coding scheme in the future
The encoding name is also significant



Unambiguously refer to a particular payload specification
Should be registered with the IANA
RED, Redundant payload type



Voice samples + previous samples
May use different encoding schemes
Cope with packet loss
Internet Telephony
36
RTP Header Format
Internet Telephony
37
The RTP Header

Version (V)


Padding (P)




2
The padding octets at the end of the payload
The payload needs to align with 32-bit boundary
The last octet of the payload contains the count
Extension (X)

1, contains a header extension
Internet Telephony
38

CSRC Count (CC)


Marker (M)



The number of contributing source indentifiers
RFC 1890
The first packet of a talkspurt, after a silence
period
Payload Type (PT)

RED is an exception


RFC 2198, the addition of headers
Sequence number


A random number at the beginning
Incremented by one for each RTP packet
Internet Telephony
39

Timestamp



32-bit
The instant at which the first sample
The receiver



Synchronized play-out
Calculate the jitter
The clock freq depends on the encoding



E.g., 8000Hz, TS=1/10 samples; TS=11
Support silence suppression
The initial timestamp is a random number
Internet Telephony
40

Synchronization Source (SSRC)






32-bit identifier
The entity setting the sequence number and
timestamp
Chosen randomly, independent of the network
address
Meant to be globally unique within the session
May be a sender or a mixer
Contributing Source (CSRC)


An SSRC value for a contributor
0-15 CSRC entries
Internet Telephony
41

RTP Header Extensions


Accommodate the common requirements of most
media streams
For payload formats that requires
Internet Telephony
42
Mixers and Translators

Mixers


Enable multiple media streams from different
sources to be combined
An audio conference



Could also change the data format
The SSRC is the mixer


If the capacity or bandwidth of a participant is limited
More than one CSRC values
A translator


Manage communications between entities that
does not support the same coding scheme
The SSRC is the participant, not the translator
Internet Telephony
43
The RTP Control Protocol (RTCP)

RTCP


A companion control protocol of RTP
Periodic exchange of control information


A third party can also monitor session quality


For quality-related feedback
Using RTCP and IP multicast
Five type of RTCP packets


Sender Report: transmission and reception statistics
Receiver Report: reception statistics
Internet Telephony
44

Source Description (SDES)


One or more
Must contain a canonical name




BYE


Separate from SSRC which might change
When both audio and video streams exist
 Have different SSRCs
 Have the same CNAME for synchronized play-out
Regular names, such as email address or phone number
The end of participation
APP

Convey application-specific functions
Internet Telephony
45

Two or more RTCP packets will be combined





SRs and RRs should be sent as often as possible
New receivers in a session must receive CNAME
An SR/RR must contain an SDES packet
A SDES packet is sent with an SR/RR even if no data to
report
An example RTP compound packet
Internet Telephony
46
RTCP Sender Report

SR




Header Info
Sender Info
Receiver report blocks
Option

Profile-specific extension
Internet Telephony
47

Resemble to a RTP packet

Version


Padding bit


2
Padding octets?
RC, report count


The number of reception report blocks
5-bit



If more than 31 reports, an RR is added
PT, payload type
SSRC of sender
Internet Telephony
48

NTP Timestamp

Network Time Protocol Timestamp



The time elapsed in seconds since 00:00, 1/1/1900 (GMT)
64-bit
 32 MSB: the number of seconds
 32 LSB: the fraction of a seconds (200 ps)
A primary time server



NTP, RFC 1305
Station WWV, Fort Collins, Colorado, by NIST
Station WWVB, Boulder, Colorado, by NIST
Internet Telephony
49

RTP Timestamp




Sender’s packet count


Corresponding to the NTP timestamp
Use the same units and has the same offset as used for
RTP timestamps
For better synchronization
Cumulative within a session
Sender’s octet count

Cumulative
Internet Telephony
50
RR blocks

SSRC_n


Fraction lost



Fraction of packets lost since the last report issued by
this participant
By examining the sequence numbers in the RTP header
Cumulative number of packets lost


The source identifier
Since the beginning of the RTP session
Extended highest sequence number received



The sequence number of the last RTP packet received
16 lsb, the last sequence number
16 msb, the number of sequence number cycles
Internet Telephony
51

Interarrival jitter


Last SR Timestamp (LSR)



An estimate of the variance in RTP packet arrival
The middle 32 bits of the NTP timestamp used in the last
SR received from the source in question
Used to check if the last SR has been received
Delay Since Last SR (DLSR)

The duration in units of 1/65,536 seconds
Internet Telephony
52
RTCP Receiver Report

RR


Issued by a participant who receives RTP packets
but does not send, or has not yet sent
Is almost identical to an SR


PT = 201
No sender information
Internet Telephony
53
RTCP Source Description Packet

Provides identification and information regarding
session participants


Header


Must exist in every RTCP compound packet
V, P, SC, PT=202, Length
Zero or more chunks of information


An SSRC or CSRC value
One or more identifiers and pieces of information



Email address, phone number, name
Defined in RFC 1889
A unique CNAME
 E.g., user@host
Internet Telephony
54

RTCP BYE Packet


Indicate one or more media sources are no longer
active
Application-Defined RTCP Packet


For application-specific data
For non-standardized application
Internet Telephony
55
Calculating Round-Trip Time


Use SRs and RRs
E.g.





Report A: A, T1 → B, T2
Report B: B, T3 → A, T4
RTT = T4-T3+T2-T1
RTT = T4-(T3-T2)-T1
Report B


LSR = T1
DLSR = T3-T2
Internet Telephony
56
Calculation Jitter

The mean deviation of the difference in
packet spacing at the receiver




Si = the RTP timestamp for packet I
Ri = the time of arrival
D(i,j) = (Rj-Sj) - (Ri- Si)
The Jitter is calculated continuously

J(i) = J(i-1) + (| D(i-1,i) | - J(i-1))/16
Internet Telephony
57
Timing of RTCP Packets

RTCP provides useful feedback



Regarding the quality of an RTP session
Delay, jitter, packet loss
Be sent as often as possible



Consume the bandwidth
Should be fixed at 5%
An algorithm, RFC 1889




Senders are collectively allowed at least 25% of
the control traffic bandwidth
The interval > 5 seconds
0.5 – 1.5 times the calculated interval
A dynamic estimate the avg RTCP packet size
Internet Telephony
58
IP Multicast

An IP diagram sent to multiple hosts



Conference
To a single address associated with all listeners
Multicast groups


Multicast address
Join a multicast group


Inform local routers
Routing protocols


Support propagation of routing information for multicast
addresses
Minimize the number of diagrams sent
Internet Telephony
59

IPv4






Multicast addresses: 224.0.0.0 – 239.255.255.255
224.0.0.1
all hosts on a local subnet
224.0.0.2
all routers on a local subnet
224.0.0.5
all routers supporting OSPF
224.0.0.9
all routers supporting RIP v.2
IGMP, Internet Group Message Protocol


Advertise membership in a group to routers
RFC 1112, 2236
Internet Telephony
60
IP Version 6

The explosive growth of the Internet






Expanded address space, 128 bits
Simplified header format
Improved support for headers and extensions
Flow-labeling capability


IPv4 address space, 32-bit
Real-time and interactive applications
Better support at the IP level for real-time ap
Authentication and privacy

At the IP level
Internet Telephony
61
IP Version 6 Header
Internet Telephony
62
IP Version 6 Header

Version


Traffic Class, 8-bit


6
For the quality of service
Flow Label, 20-bit



Label sequences of packets
A flow := source address, destination address,
flow label
0, no special handling
Internet Telephony
63

Payload Length, 16-bit unsigned integer



The length of payload in octets
Header extensions are part of the payload
Next Header, 8-bit

The next higher-layer protocol



The existence of IPv6 header extensions
Hop Limit, 8-bit unsigned integer


Same as the IPv4
The TTL field of the IPv4 header
Source and Destination Addresses, 128-bit
Internet Telephony
64
IP version 6 addresses

XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX


E.g., 1511:1:0:0:0:FA22:45:11



Leading zeros are omitted
= 1511:1::FA22:45:11
0:0:0:0:AA11:50:22:F77 = ::AA11:50:22:F77


X is a hexadecimal character
“::” can appears only once
Should not generally require significant changes to
up-layer protocols

But the checksum calculation in UDP and TCP includes a
pseudo header
Internet Telephony
65
IP version 6 special addresses

The all-zeros address, ::


The loopback address, ::1


On a virtual internal interface
IPv6 address with embedded IPv4 address (type 1)



An unspecified address; a node does not yet know its
address
96-bit zeros + 32-bit IPv4 address
::140.113.17.5
IPv6 address with embedded IPv4 address (type 2)



80-bit zeros + FFFF + 32-bit IPv4 address
0:0:0:0:0:FFFF:140.113.17.5
::FFFF:140.113.17.5
Internet Telephony
66
IP Version 6 Header Extensions

Extension Headers

Are not acted upon by intermediate nodes


With one exception
Next Header




The type of payload carried in the IP datagram
The type of header extension
Each extension has its own next header field
An example
Internet Telephony
67
Header extension

Use the next header field
Internet Telephony
68
Hop-by-hop extension

The exception header extension





Next header
Length


Examined and processed by every intermediate node
If present, must immediately follow the IP header
Of variable length
in units of eight octets, not including the first eight
octets
Options

TLV (Type-Length-Value) format


8-bit, 8-bit (in units of octets), variable length
Type [0:2] of special significance
Internet Telephony
69

Hop-by-hop header extension
Internet Telephony
70

Type[0:1]





00 skip this option and continue processing the header
01 discard the packet
10 discard the packet and send an ICMP Parameter
Problem, Code 2 message to the originator of the packet
11 do above only if the destination address in the IP
header is not a multicast address
Type[2]


1, the option data can be changed
0, cannot
Internet Telephony
71

Destination options extension




Has the same format as the hop-by-hop extension
Only the destination node examine the extension
Header type = 60
Routing Extension





A routing type field to enable various routing
options
Only routing type 0 is defined for now
Specify the nodes that should be visited
Next header
Length
Internet Telephony
72

Routing Extension
Internet Telephony
73


Routing type
Segments Left



The number of nodes that still need to be visited
A list of IP addresses needs to be visited
Is this type of header analyzed by intermediate
node?






Yes or no
A->Z, 3, (B,C,D)
A->B, 3, (C,D,Z)
A->C, 2, (B,D,Z) by B
A->D, 1, (B,C,Z) by C
A->Z, 0, (B,C,D) by D
Internet Telephony
74
Interoperation IPv4 and IPv6

IPv4 and IPv6 will coexist for a long time




IPv4 nodes  IPv6 nodes
IPv6 nodes  IPv6 nodes via IPv4 networks
IPv4 nodes  IPv4 nodes via IPv6 networks
IPv4-compatible nodes with IPv4-compatible
addresses at the boundaries of IPv6 networks

IPv6 in IPv4 packets
Internet Telephony
75
Interoperation IPv4 and IPv6

IPv4-compatible nodes with IPv4-compatible
addresses at the boundaries of IPv6 networks

IPv6 in IPv4 packets
Internet Telephony
76