陳懷恩博士助理教授兼所長國立宜蘭大學資訊工程研究所 TEL: # 255

Transcription

1 Introduction ti to VoIP 陳懷恩博士助理教授兼所長國立宜蘭大學資訊工程研究所 TEL: # 55

2 Outline Introduction VoIP Call Tpyes VoIP Equipments Speech and Codecs Transport Protocols Real-time Transport Protocol

3 What is VoIP? Transport voice traffic using the Internet Protocol (IP) One of the greatest challenges to VoIP is voice quality. One of the keys to acceptable voice quality is bandwidth. Control and prioritize the access Internet: best-effort transfer VoIP!= Internet telephony The next generation Telcos Access and bandwidth are better managed. 3

4 Carrier Grade VoIP Carrier grade Extremely high availability % reliability (high reliability) Fully redundant, d Self-healing li AT&T carries about 3 million voice calls a day (high capacity). Highly scalable Short call setup time, high speech quality No perceptible echo, noticeable delay and annoying noises on the line Carrier grade and VoIP mutually exclusive A serious alternative ti for voice communications with enhanced features 4

5 Traffic Types: Data and Voice Data traffic Asynchronous - can be delayed Extremely error sensitive Voice traffic Synchronous -stringent ti tdl delay requirements More tolerant for errors Note that IP is not designed dfor voice delivery. VoIP requirements Meet all the requirements for traditional telephony Offer new and attractive capabilities at a lower cost 5

6 Why VoIP? Why carry voice? Internet supports instant access to anything However, voice services provide more revenues. Voice is big business. Why use IP for voice? Traditional telephony carriers use circuit switching for carrying voice traffic. Circuit-switching is not suitable for multimedia communications. IP: lower equipment cost, low operating expense, integration of voice and data applications, potentially lower bandwidth requirements, the widespread availability of IP 6

7 VoIP Call Types Computer Internet Voice Gateway Phone Line Computer Internet Voice Gateway Voice Gateway Phone Line Computer Internet Phone Line 7

8 The VoIP Equipments () Telephone hardwares of the network Pingtel xpressa CISCO796 snom 8

9 The VoIP Equipments () USB Phone, Mike of earphone, to need, then install the network telephone software (on computers) MSN Messenger 9

10 The VoIP Equipments (3) Home Voice Gateway (telephone) Source of the photo: ARTDIO Company

11 The VoIP Equipments (4) Call Server (a) PSTN Gateway (b) (a) Vontel Server (b) CISCO Gateway

12 Lower Bandwidth Requirements PSTN Human speech frequency < 4K Hz The Nyquist Theorem: *4k samples per second G.7-64 kbps = 8K * 8 bits Sophisticated coders Save more bandwidth by silence-detection Compression 3kbps, 6kbps, 8kbps, 6.3kbps, 5.3kbps GSM 3kbps Traditional telephony never changes. VoIP two ends of the call negotiate the coding scheme

13 VoIP Challenges VoIP must offer the same reliability and voice quality as PSTN % and Toll quality Mean Opinion Score (MOS) 5 (Excellent), 4 (Good), 3 (Fair), (Poor), (Bad) International Telecommunication Union Telecommunications Standardization Sector (ITU-T) T) P.8 Toll quality means a MOS of 4. or better. 3

14 Speech Quality (/3) Must be as good as PSTN Delay Coding/Decoding + Buffering Time + Tx. Time G.4: the round-trip time 3 ms Echo High Delay ==> Echo is Critical speak listen 4

15 Speech Quality (/3) Jitter Delay variation Due to different routes or queuing times Use of jitter buffer (possible solution) Jitter buffers add delay speak speak listen listen constant t delay variance = variable delay variance <> 5

16 Speech Quality (3/3) Packet Loss Traditional retransmission cannot meet the real-time requirements Call Setup Time Address Translation (DNS Query) Directory Access (Query Database) ENUM or LDAP 6

17 Managing g Access and Prioritizing Traffic A single network for a wide range of applications Resource management: call is admitted if sufficient resources are available Prioritization: different types of traffic are handled in different ways If a network becomes heavily loaded, traffic should feel the effects before synchronous traffic (such as voice). QoS has required huge efforts 7

18 Speech-coding coding Techniques In general, coding techniques are such that speech quality degrades as bandwidth reduces. The relationship is not linear. 8

19 Network Reliability and Scalability % reliability Today s VoIP solutions are ok. Redundancy and load sharing Scalable easy to start on a small scale and then expand as traffic demand increases Distributed architecture 9

20 Components of VoIP Coding & Decoding of Analog Voice Analog-to-Digital and Digital-to-Analogto conversions Compression Signaling Call setup & tear down Resource & coding negotiation Transport of Bearer Traffic Voice packet transmission Routing Support of quality of service Numbering Phone number, IP address

21 VoIP Protocols H.33: ITU-T T standard, latest version v4 Peer-to-peer protocol that supports terminals communicating over packet based networks SIP: IETF standard, RFC 36 Peer-to-peer protocol for initiation, modification termination of communication sessions between users MGCP: ITU-T T and IETF collaboration, RFC 3435 Master/slave protocol for media gateway controller to control media gateway

22 VoIP Protocol Stacks

23 The IP suite and the OSI stack TCP UDP Reliable, error-free, in-sequence delivery No sequencing, no retransmission 3

24 IP and TCP Internet Protocol (IP) A packet-based protocol Routing on a packet-by-packet base Packets transfer with no guarantees May not receive in order May be lost or severely delayed Transmission Control Protocol (TCP) Retransmission Assemble the packets in order Congestion control Useful for file-transfers and User Datagram Protocol (UDP) No retransmission, flow control and sequence number Useful for real-time transmission 4

25 IP RFC 79 Amendments: RFCs 95, 99, and 9 Requirements for Internet hosts: RFCs, 3 Requirements for IP routers: RFC 8 IP datagram Data packet with an IP header Best-effortprotocol effort No guarantee that a given packet will be delivered 5

26 IP Header [/] Version 4 Header Length Type of Service Total Length Identification, Flags, and Fragment Offset TTL A datagram can be split into fragments Identify data fragments Flags a datagram can be fragmented or not Indicate the last fragment A number of hops (not a number of seconds) 6

27 IP Header [/] Protocol The higher-layer protocol TCP (6); UDP (7) Source and Destination IP Addresses Version Header Type of Service Total Length Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum 8 9 Source IP Address Destination IP Address Options Data 7

28 TCP Transmission Control Protocol In sequence, without omissions and errors End-to-end confirmation, packet retransmission,flow control, congestion 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 is received within a given period. 8

29 The TCP Header [/5] The TCP Header [/5] Source Port Destination Port Acknowledge Number Sequence Number Ch k Data Offset Reserved U R G A C K P S H R S T S Y N F I N U tp i t Window Options Checksum Urgent Point Padding Data 9

30 The TCP Header [/5] TCP Port Numbers Identifying a specific instance of a given application A unique port number for a particular session Well-known port numbers IANA, -3 3, telnet; 5, SMTP Many clients and a server TCP/IP Source address and port number + Destination address and port number A socket address (or a transport address) 3

31 The TCP Header [3/5] Sequence and acknowledge numbers Identify individual segments Actually count data octets transmitted A given segment with a SN of and contains 5 octets of data The ack number will be 5 The SN of the next segment is 5 Other header fields Data offset: header length (in 3-bit words) URG: if urgent data is included, use urgent pointer field 3

32 The TCP Header [4/5] ACK:, an ACK PSH: for the push function 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 3

33 The TCP Header [5/5] 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 33

34 TCP Connections An example Client Server After receiving,, 3 ACK 4 Closing a connection SYN FIN ACK, FIN Seq = Window size MSS ACK SYN Seq = 4 ACK = Window size MSS Seq = ACK = 4 34

35 UDP User Datagram Protocol Pass individual pieces of data from an application to IP No ACK, inherently unreliable Applications A quick, on-shot transmission of data, request/response DNS If no response, the AP retransmits the request The AP includes a request identifier The source port number is optional Checksum Source Port Destination Port Length Checksum 35

36 Voice over UDP, not TCP Speech Small packets, 4 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 36

37 The Real-Time Transport Protocol RTP: A Transport Protocol for Real-Time Applications RFC 355 (Obsoletes RFC 889) 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 37

38 RTCP A companion protocol Exchange messages between session users # of flost packets, dl delay and dinter-arrival i ljitter Quality feedback RTCP is implicitly open when an RTP session is open RTP/RTCP uses UDP port n and n+ (e.g., 5/5) 38

39 RTP Payload Formats [/] RTP carries the actual digitally encoded voice RTP header + a payload of voice/video samples UDP and IP headers are attached Many voice- and video-coding standards A payload type identifier in the RTP header Specified in RFC 355 New coding schemes have become available See Table and Table for examples A sender has no idea what coding schemes a receiver could handle. 39

40 RTP Payload Formats [/] Separate signaling gsystems Capability negotiation during the call setup SIP and SDP A dynamic payload type may be used 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 (refer to RFC98) To cope with packet loss Primary Voice samples + previous samples Two samples may use different encoding schemes 4

41 Payload Types for Audio Encoding Table. Example of payload types of audio encoding Payload Type Name Media Type Clock Rate (Hz) Channel PCMU Audio 8 G76-3 Audio 8 3 GSM Audio 8 4 G73 Audio 8 8 PCMA Audio 8 8 G79 Audio 8 4

42 Payload Types for Video Encoding Table. Example of payload types of video encoding Payload Type Name Media Type Clock Rate (Hz) 5 CelB Video 9 6 JPEG Video 9 3 H6 Audio 9 3 MPV Audio 9 33 MPT Video/Audio 9 34 H63 Video 9 Dyn H Video 9 4

43 RTP Header Format RTP Header RTP Header Extension 43

44 The RTP Header [/4] Version (V) Padding (P) The padding octets at the end of the payload The payload needs to align with 3-bit boundary The last octet of the payload contains a count of the padding octets. Extension (X), contains a header extension 44

45 The RTP Header [/4] CSRC Count (CC) The number of contributing source identifiers Marker (M) Support silence suppression The first packet of a talkspurt, after a silence period Payload Type (PT) In general, a single RTP packet will contain media coded according to only one payload format. RED is an exception. Sequence number A random number generated by the sender at the beginning of a session Incremented by one for each RTP packet 45

46 The RTP Header [3/4] Timestamp 3-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., 8Hz Support silence suppression The initial timestamp is a random number chosen by the sending application. 46

47 The RTP Header [4/4] Synchronization Source (SSRC) 3-bit identifier The entity setting the sequence number and timestamp Chosen randomly, independent of the network address Meant to be globally unique within a session May be a sender or a mixer Contributing Source (CSRC) An SSRC value for a contributor Used to identify the original sources of media behind the mixer -5 CSRC entries 47

48 Mixers and Translators Mixers Enable multiple media streams from different sources to be combined into a single stream If the capacity or bandwidth of a participant is limited An audio conference The SSRC is the mixer More than one CSRC values Translators Manage communications between entities that does not support the same coding scheme The SSRC is the participant, not the translator. 48

49 The RTP Control Protocol [/3] RTCP A companion control protocol of RTP Periodic exchange of control information For quality-related feedback A third party can also monitor session quality and detect network problems. Using RTCP and IP multicast Five types of RTCP packets Sender Report: transmission and reception statistics Receiver Report: reception statistics 49

50 The RTP Control Protocol [/3] Source Description (SDES) One or more descriptions related to a particular session participant Must contain a canonical name (CNAME) Separate from SSRC which might change When both audio and video streams were being transmitted, the two streams would have different SSRCs the same CNAME for synchronized play-out BYE APP The end of a participation in a session For application-specific functions 5

51 The RTP Control Protocol [3/3] Two or more RTCP packets will be combined SRs and RRs should be sent as often as possible to allow better statistical resolution. New between media sources and the received media. receivers in a session must receive CNAME very quickly to allow a correlation Every RTCP packet must contain a report packet (SR/RR) and an SDES packet Even if no data to report An example RTP compound packet 5

52 RTCP Sender Report Sender Report Header Info Sender Info Receiver Report Blocks Option Profile-specific ifi extension 5

53 Header Info Resemble to an RTP packet Version Padding bit Padding octets? RC, report count The number of reception report blocks 5-bit If more than 3 reports, an RR is added PT, payload type () 53

54 Sender Info SSRC of sender NTP Timestamp Network Time Protocol Timestamp The time elapsed in seconds since :, //9 (GMT) 64-bit 3 MSB: the number of seconds 3 LSB: the fraction of a seconds ( ps) RTP Timestamp Corresponding to the NTP timestamp The same as used for RTP timestamps For better synchronization Sender s packet count Cumulative within a session Sender s octet count Cumulative within a session 54

55 RR Blocks [/] SSRC_ n The source identifier of the session participant to which the data in this RR block pertains. 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 6 lsb, the last sequence number 6 msb, the number of sequence number cycles 55

56 RR Blocks [/] Interarrival jitter An estimate of the variance in RTP packet arrival Last SR Timestamp (LSR) Used to check if the last SR has been received Delay Since Last SR (DLSR) The duration in units of /65,536 seconds 56

57 RTCP Receiver Report Receiver Report Issued by a participant who receives RTP packets but does not send, or has not yet sent Is almost identical to an SR PT = No sender information 57

58 RTCP Source Description Packet Provides identification and information regarding g session participants Must exist in every RTCP compound packet Header V, P, SC, PT=, Length Zero or more chunks of information An SSRC or CSRC value One or more identifiers and pieces of information A unique CNAME address, phone number, name 58

59 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 59

60 Calculating Round-Trip Time Use SRs and RRs E.g. Report A: A, T B, T A B Report B: B, T3 A, T4 RTT = T4-T3+T-TT3+T T RTT = T4-(T3-T)-T Report B LSR = T DLSR = T3-T T A T T T3 T4 6

61 Calculation Jitter The mean deviation of the difference in packet spacing at the receiver S i = the RTP timestamp for packet i R i = the time of arrival D(i,j) = (R j -S j ) - (R i - S i ) The Jitter is calculated continuously J(i) = J(i-) + ( D(i-,i) i) - J(i-))/6 6

62 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 889 Senders are collectively allowed at least 5% of the control traffic bandwidth. (CNAME) The interval > 5 seconds.5.5 times the calculated interval A dynamic estimate the avg. RTCP packet size 6