1. Transporting Voice by Using IP
Chapter 2

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
2
Internet Telephony

3. Internet Overview

Interconnecting networks

Routers provides the connectivity
3
Internet Telephony

4. 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
4
Internet Telephony

5. OSI seven-layer stack
5
Internet Telephony

6. OSI seven-layer model

Physical layer



Data link layer



The physical media
Coding and modulation schemes for 1s and 0s
Transport the information over a single link
Frame packaging, error detection/correction and
retransmission
Network layer


Routing traffic through a network
Passing through intermediate points
6
Internet Telephony

7. 
Transport layer



Ensure error-free, omission-free and in-sequence
delivery
Support multiple streams from the source to
destination for applications
Session layer


The commencement (e.g., login) and completion
Establish the dialogue

One way at a time or both ways at the same time
7
Internet Telephony

8. 
Presentation layer


Specify the language, the encoding (e.g. ASCII or
binary)
Application layer


Provide an interface to the user
FTP, Web browsers
8
Internet Telephony

9. The IP suite and the OSI stack

TCP


Reliable, error-free, in-sequence delivery
UDP

No sequencing, no retransmission
9
Internet Telephony

10. Internet Standards and the Process

The Internet Society




A non-profit 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
10
Internet Telephony

11. 
IAB




The Internet Architecture Board
The technical advisory group
Technical guidance, oversee the Internet
standards process
IETF




Comprises a huge number of volunteers
Develop Internet standards
Detailed technical work
Working groups

avt, megaco, iptel, sip, sigtran
11
Internet Telephony

12. 
IESG





The Internet Engineering Steering Group
Manage the IETF’s activities
Approve an official standard
Can a standard advance?
IANA

The Internet Assigned Numbers Authority


Unique numbers and parameters used in Internet
standards
Be registered with the IANA
12
Internet Telephony

13. 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
13
Internet Telephony

14. 
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
14
Internet Telephony

15. 
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
15
Internet Telephony

16. 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
16
Internet Telephony

17. 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)
17
Internet Telephony

18. 
Protocol



The higher-layer protocol
TCP, 6; UDP, 17
Source and Destination IP Addresses
18
Internet Telephony

19. 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
19
Internet Telephony

20. 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
20
Internet Telephony

21. 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
21
Internet Telephony

22. 
The TCP header
22
Internet Telephony

23. 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
23
Internet Telephony

24. 
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
24
Internet Telephony

25. 



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
25
Internet Telephony

26. 
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.
26
Internet Telephony

27. TCP Connections


An examples
After receiving



100, 200, 300
ACK 400
Closing a connection



> FIN
< ACK, FIN
> ACK
27
Internet Telephony

28. 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
28
Internet Telephony

29. 
UDP header
29
Internet Telephony

30. 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
30
Internet Telephony

31. 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
31
Internet Telephony

32. 
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
32
Internet Telephony

33. 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
33
Internet Telephony

34. 
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
34
Internet Telephony

35. RTP Header Format
35
Internet Telephony

36. 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
36
Internet Telephony

37. 
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
37
Internet Telephony

38. 
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
38
Internet Telephony

39. 
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
39
Internet Telephony

40. 
RTP Header Extensions


Accommodate the common requirements of most
media streams
For payload formats that requires
40
Internet Telephony

41. 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
41
Internet Telephony

42. 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
42
Internet Telephony

43. 
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
43
Internet Telephony

44. 
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
44
Internet Telephony

45. RTCP Sender Report

SR




Header Info
Sender Info
Receiver report blocks
Option

Profile-specific extension
45
Internet Telephony

46. 
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
46
Internet Telephony

47. 
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
47
Internet Telephony

48. 
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
48
Internet Telephony

49. 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
49
Internet Telephony

50. 
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
50
Internet Telephony

51. 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
51
Internet Telephony

52. 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
52
Internet Telephony

53. 
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
53
Internet Telephony

54. 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
54
Internet Telephony

55. Calculation Jitter

The mean deviation of the difference in
packet spacing at the receiver


Ri = the time of arrival


Si = the RTP timestamp for packet I
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
55
Internet Telephony

56. 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
56
Internet Telephony

57. 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
57
Internet Telephony

58. 
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
58
Internet Telephony

59. 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
59
Internet Telephony

60. IP Version 6 Header
60
Internet Telephony

61. 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
61
Internet Telephony

62. 
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
62
Internet Telephony

63. IP version 6 addresses

XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XX
XX


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
63
Internet Telephony

64. 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
64
Internet Telephony

65. 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
65
Internet Telephony

66. Header extension

Use the next header field
66
Internet Telephony

67. 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
67
Internet Telephony

68. 
Hop-by-hop header extension
68
Internet Telephony

69. 
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
69
Internet Telephony

70. 
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
70
Internet Telephony

71. 
Routing Extension
71
Internet Telephony

72. 

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
72
Internet Telephony

73. 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
73
Internet Telephony

74. Interoperation IPv4 and IPv6

IPv4-compatible nodes with IPv4-compatible
addresses at the boundaries of IPv6 networks

IPv6 in IPv4 packets
74
Internet Telephony