Transporting Voice by Using IP

1
Transporting Voice by Using IP

• Chapter 2

2
Internet Overview

• A collection of networks
• The private networks
• LANs, MANs, WANs
• Institutions, corporations, business and
  government
• May use various communication protocols
• The public networks
• ISP Internet Service Providers
• Using Internet Protocol
• To connect to the Internet
• Using IP

3
Internet Overview

• Interconnecting networks
• Routers provides the connectivity

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

5
The IP suite and the OSI stack

• TCP
• Reliable, error-free, in-sequence delivery
• UDP
• No sequencing, no retransmission

6
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

7

• 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

8

• IETF, formed in 1986
• Comprises a huge number of volunteers
• We reject kings, presidents and voting. We
  believe in rough consensus and running code,
  Dave Clark
• Develop Internet standards
• standards only when people use them
• Detailed technical work
• Working groups (gt100)
• avt, megaco, iptel, sip, sigtran

9

• IESG,The Internet Engineering Steering Group
• Area Directors IETF Chair
• Manage the IETFs activities
• Approve an official standard
• Can a standard advance?

10

• IANA,The Internet Assigned Numbers Authority
• Unique numbers and parameters used in Internet
  standards
• Be registered with the IANA
• IP addresses
• mostly delegated to IP 5 regional Address
  registries
• domain names
• 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

11

• 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

12
Top Level View of Organization

the IETF
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
• IETFs Internet Drafts directory
• Six-month life-time

14

• RFC
• Request for Comments
• An RFC number
• Proposed standard
• 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

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)
• Processes, policies, or operational
  considerations
• Others applicability statements
• How a spec be used, or different specs work
  together
• STD1 list the various RFCs

16
IPR (Patents)

• RFC 2026 revised IETF IPR rules
• used to require fair non-discriminatory
  licensing
• some standards blocked using old process
• now use standards sequence to check IPR issues
• 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

17
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

18
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

19
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)

20

• Protocol
• The higher-layer protocol
• TCP, 6 UDP, 17
• Source and Destination IP Addresses

21
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

22
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

23
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

24

• The TCP header

25
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

26

• 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

27

• 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

28

• 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.

29
TCP Connections

• An examples
• After receiving
• 100, 200, 300
• ACK 400
• Closing a connection
• gt FIN
• lt ACK, FIN
• gt ACK

30
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

31

• UDP header

32
Voice over UDP, not TCP

• Speech
• Small packets, 10 40 ms
• Occasional packet loss is not a catastrophe
• Delay-sensitive
• TCP connection set-up, ack, retransmit ? delays
• 5 packet loss is acceptable if evenly spaced
• Resource management and reservation techniques
• A managed IP network
• In-sequence delivery
• Mostly yes
• UDP was not designed for voice traffic

33
The Real-Time Transport Protocol

• RTP A Transport Protocol for Real-Time
  Applications
• RFC 1889
• RTP Real-Time Transport Protocol
• RTCP RTP Control Protocol
• UDP
• 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

34

• 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

35
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

36

• 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

37
RTP Header Format
38
The RTP Header

• Version (V)
• 2
• Padding (P)
• 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

39

• CSRC Count (CC)
• The number of contributing source indentifiers
• Marker (M)
• 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

40

• 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, TS1/10 samples TS11
• Support silence suppression
• The initial timestamp is a random number

41

• 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

42

• RTP Header Extensions
• Accommodate the common requirements of most media
  streams
• For payload formats that requires

43
Mixers and Translators

• Mixers
• Enable multiple media streams from different
  sources to be combined
• An audio conference
• If the capacity or bandwidth of a participant is
  limited
• Could also change the data format
• The SSRC is the mixer
• 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

44
The RTP Control Protocol (RTCP)

• RTCP
• A companion control protocol of RTP
• Periodic exchange of control information
• For quality-related feedback
• A third party can also monitor session quality
• Using RTCP and IP multicast
• Five type of RTCP packets
• Sender Report transmission and reception
  statistics
• Receiver Report reception statistics

45

• Source Description (SDES)
• One or more
• Must contain a canonical name
• 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
• BYE
• The end of participation
• APP
• Convey application-specific functions

46

• 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

47
RTCP Sender Report

• SR
• Header Info
• Sender Info
• Receiver report blocks
• Option
• Profile-specific extension

48

• Resemble to a RTP packet
• Version
• 2
• Padding bit
• 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

49

• NTP Timestamp
• Network Time Protocol Timestamp
• The time elapsed in seconds since 0000, 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

50

• RTP Timestamp
• Corresponding to the NTP timestamp
• Use the same units and has the same offset as
  used for RTP timestamps
• For better synchronization
• Senders packet count
• Cumulative within a session
• Senders octet count
• Cumulative

51
RR blocks

• SSRC_n
• The source identifier
• 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
• 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

52

• Interarrival jitter
• An estimate of the variance in RTP packet arrival
• Last SR Timestamp (LSR)
• 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

53
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

54
RTCP Source Description Packet

• Provides identification and information regarding
  session participants
• Must exist in every RTCP compound packet
• Header
• V, P, SC, PT202, 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_at_host

55

• 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

56
Calculating Round-Trip Time

• Use SRs and RRs
• E.g.
• Report A A, T1 ? B, T2
• Report B B, T3 ? A, T4
• RTT T4-T3T2-T1
• RTT T4-(T3-T2)-T1
• Report B
• LSR T1
• DLSR T3-T2

57
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

58
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 gt 5 seconds
• 0.5 1.5 times the calculated interval
• A dynamic estimate the avg RTCP packet size

59
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

60

• 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

61
IP Version 6

• The explosive growth of the Internet
• IPv4 address space, 32-bit
• Real-time and interactive applications
• Expanded address space, 128 bits
• Simplified header format
• Improved support for headers and extensions
• Flow-labeling capability
• Better support at the IP level for real-time ap
• Authentication and privacy
• At the IP level

62
IP Version 6 Header
63
IP Version 6 Header

• Version
• 6
• Traffic Class, 8-bit
• 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

64

• 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
• Same as the IPv4
• The existence of IPv6 header extensions
• Hop Limit, 8-bit unsigned integer
• The TTL field of the IPv4 header
• Source and Destination Addresses, 128-bit

65
IP version 6 addresses

• XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
• X is a hexadecimal character
• E.g., 15111000FA224511
• Leading zeros are omitted
• 15111FA224511
• 0000AA115022F77 AA115022F77
• 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

66
IP version 6 special addresses

• The all-zeros address,
• An unspecified address a node does not yet know
  its address
• The loopback address, 1
• On a virtual internal interface
• IPv6 address with embedded IPv4 address (type 1)
• 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
• 00000FFFF140.113.17.5
• FFFF140.113.17.5

67
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

68
Header extension

• Use the next header field

69
Hop-by-hop extension

• The exception header extension
• Examined and processed by every intermediate node
• If present, must immediately follow the IP header
• Of variable length
• Next header
• 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 02 of special significance

70

• Hop-by-hop header extension

71

• Type01
• 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
• Type2
• 1, the option data can be changed
• 0, cannot

72

• 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

73

• Routing Extension

74

• 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-gtZ, 3, (B,C,D)
• A-gtB, 3, (C,D,Z)
• A-gtC, 2, (B,D,Z) by B
• A-gtD, 1, (B,C,Z) by C
• A-gtZ, 0, (B,C,D) by D

75
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

76
Interoperation IPv4 and IPv6

• IPv4-compatible nodes with IPv4-compatible
  addresses at the boundaries of IPv6 networks
• IPv6 in IPv4 packets