Voice over IP

• Course webpage: http://solomon.ipv6.club.tw/Course/VoIP/
• Textbook: "Carrier Grade Voice over IP" by Daniel Collins, published by McGraw-Hill.
• Students enroll in this class
• TA: 林穎舜 ,陳瑞邦 4807 0911707827

Presentation Tips

1. Do not present RFC words by words. It would be boring.
2. Include more figures
3. Give examples
4. Read related documents whenever it is necessary.

Presentation List

1. RFC 3485 - SIP and SDP Static Dictionary for Signaling Compression (SigComp) (pages 30) (張兢真)
2. RFC 3486 - Compressing the Session Initiation Protocol (12 pages)
   • This document defines two parameters, one for SIP URIs and the other for the Via header field.
   • The presence of parameter "comp=sigcomp" in a URI indicates that the request has to be compressed using SigComp.
     • This URI may not be the Request-URI. Autally, it is referred to as the next-hop URI, which might be the Request-URI of the request or an entry in the Route header field.
   • The presence of "comp=sigcomp" in a Via header field indicates that the response has to be compressed using SigComp.
   • Example in Section 9
   • Q: For the first request, the UAC is not sure of whether the UAS supports SigComp, so this request is not compressed. How can you improve it?
3. RFC 4168 - The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP). (10 pages + demo) (陳柏州)
4. RFC 3711 - Secure RTP (SRTP) (56 pages) (王鐘逸)
5. RFC 3856 - A Presence Event Package for SIP (27 pages) (張文萍)
   1. Event: presence
      Accept: application/pidf+xml
   2. Presence User Agents (PUA) push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages or send NOTIFY messages.
   3. Presence Agent (PA) must have access to presence data manipulated by PUAs for the presentity. One way to do this is by co-locating the PA with the proxy/registrar. Another way is to co-locate it with the presence user agent.
   4. A presentity is identified in the form pres:user@domain (RFC 3859).
   5. Q: If a user has both a SIP (and/or SIPS) URI and a pres URI to identify, how do these URIs relate to each other in providing the presentity?
      A:
      • a SUBSCRIBE request sent to a pres URI will result in learning a SIP or SIPS URI for the presentity from the Contact header field of the 200 OK
      • a DNS mechanism might be defined that would allow lookup of a pres URI to obtain a SIP or SIPS URI
      • See RFC 3861 - Address Resolution for Instant Messaging and Presence.
      • Note: some proxies may not recognize the pres: scheme, so it may reject the SUBSCRIBE request. It is recommended earlier deployment systems only provide users with a SIP URI.
   6. Authorization decisions can be very complex. Ultimately, all authorization decisions can be mapped into one of three states: rejected, successful, and pending.
   7. The appropriate response codes for conveying a successful, rejected, or pending subscription are 200, 403 or 603, and 202, respectively, as described in RFC 3265
   8. Filter
   9. Future extensions can be defined that allow a subscriber to request that the notifications contain changes in presence information only, rather than complete state.
   10. For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request.
   11. This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request.
   12. Whenever the PA is not co-located with the PUA for the presentity, the PA is acting as a state agent (presence server). It collects presence state from the PUA, and aggregates it into a presence document.
   13. Because there can be multiple PUA, a centralized state agent is needed to perform this aggregation.
   14. 6.11.2. Migration: the PA function may reside in the presence server when the PUA is not running, but when the PUA connects to the network, the PA migrates subscriptions to it in order to reduce state in the network.
6. RFC 4240 - Basic Network Media Services with SIP (24 pages) (施賢孝)
   1. Without a well-known relationship between service and service address, how would the client locate the service?
   2. the service indicator is case insensitive, the service instance identifier is also case insensitive.
   3. If the media server cannot perform the requested service or does not recognize the service indicator, it MUST respond with the response code 488 NOT ACCEPTABLE HERE. (606 is not appropriate, as some other media server may be able to satisfy the request.)
   4. if a service requires an existing service instance, and no such service instance exists on the media server, the media server MUST respond with the response code 404 NOT FOUND.
   5. Announcement Service
      1. The user portion of the address, "annc", specifies the announcement service on the media server.
      2. The "play=" parameter is mandatory and MUST be present. All other parameters are OPTIONAL.
      3. sip:annc@ms2.example.net; \ play=file://fileserver.example.net//geminii/yourHoroscope.wav
   6. Prompt and Collect Service
      1. the service indicator is "dialog"
      2. a parameter, voicexml=, indicating the URI of the VoiceXML script to execute.
      3. sip:dialog@mediaserver.example.net; \ voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
   7. Conference Service
      1. sip:conf=uniqueIdentifier@mediaserver.example.net
      2. the conference URI shared between the application and media servers provides enhanced security, as the SIP control interface (of media servers) does not have to be exposed to participants.
7. RFC 4458 - URIs for Applications such as Voicemail and Interactive Voice Response (IVR) (21 pages) (施賢孝)
8. RFC 4353 - A Framework for Conferencing with SIP (29 pages) (黃育成)
9. RFC 4597 - Conferencing Scenarios (17 pages) (黃育成)
10. RFC 3666 - SIP PSTN Call Flows (118 pages) (陳柏志)
11. Organizing a live call-in TV show about computers, ACM SIGUCCS conference on User Services, pp. 231-235, Kansas, Missouri, 1987.
12. RFC 4566 - SDP: Session Description Protocol (49 pages) (陳冠榮)
13. RFC 3994 - Indication of Message Composition for Instant Messaging (13 pages) (李宗儒)
14. RFC 4103 - RTP Payload for Text Conversation (20 pages) (李宗儒)
    • Q: Redundant data that would need a timestamp offset higher than 16383 (2^14) MUST NOT be included in transmitted packets.
    • All T140blocks, from the oldest desired generation up through the generation immediately preceding the new (primary) T140block, MUST be included.
    • T.140 data MAY be buffered for transmission with a maximum buffering time of 500 ms. A buffering time of 300 ms is RECOMMENDED.
    • Sending an empty T140block indicates the beginning of an idle period. This can help you to distinguish the idle time vs. packet loss.
    • Packet loss for text/t140 packets MAY be detected by observing gaps in the sequence numbers of RTP packets received by the receiver.
    • How is its redundancy protection compared with sending text over TCP?

    ---

15. RFC 3389 - RTP Payload for Comfort Noise
16. RFC 4568 - Session Description Protocol (SDP) Security Descriptions for Media Streams
17. RFC 2445 - Internet Calendaring and Scheduling (iCalendar)
18. RFC 3320 - Signaling Compression (62 pages)
    1. SigComp is offered to applications as a layer between the application and an underlying transport.
    2. The application may return a compartment identifier if it wishes to allow state to be saved for the message.
    3. All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port.
    4. The function of dispathcers is to provide an interface between SigComp and its environment, minimizing the effort needed to integrate SigComp into an existing protocol stack.
    5. Q: You have multiple compressors, why do you only have one UDVM?
    6. Q: What states need to be stored between SigComp messages?
       A: For example, bytecode (Section 5.1). If you need to include the bytecode in each message, the compression ratio will be relatively low.
    7. Q: What is the time taken by compression? What is the time saved in call setup by the compressed message?
       Note: The code size of a typical algorithm is small (often sub 100 bytes).
    8. Q: Why do you want to use a virtual machine for decompression?
       A: The motivation for creating the UDVM is to provide flexibility when choosing how to compress a given application message. (Section 8)
    9. Ref: RFC 1951 - DEFLATE Compressed Data Format
19. RFC 2736 - Guidelines for Writers of RTP Payload Format Specifications (10 pages)
20. RFC 4040 - RTP Payload Format for a 64 kbit/s Transparent Call (8 pages)
21. RFC 4710 - Real-time Application Quality-of-Service Monitoring (RAQMON) Framework
22. RFC 3261 Section 22 - Usage of HTTP Authentication (RFC 2617)
23. RFC 4032 - Update to SIP Preconditions Framework
24. RFC 4060 - RTP Payload Formats for European Telecommunications Standards Institute (ETSI)
25. RFC 4080 Next Steps in Signaling (NSIS): Framework
26. RFC 4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
27. 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
28. 4097 Middlebox Communications (MIDCOM) Protocol Evaluation
29. 4134 Examples of S/MIME Messages
30. 4146 Simple New Mail Notification
31. 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
32. RFC 4567 - Key Management Extensions for SDP
33. RFC 4568 - SDP Security Descriptions for Media Streams
34. RFC 4288 - Media Type Specifications and Registration Procedures
35. RFC 3629 - UTF-8, a transformation format of ISO 10646
36. RFC 3605 - Real Time Control Protocol (RTCP) attribute in SDP
37. RFC 3840 - Indicating User Agent Capabilities in SIP
38. RFC 3714 - IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet
    • technologies that can be deployed without changes to the infrastructure enjoy considerable advantages in the speed of deployment.
    • a brief demonstration was made of VoIP over a shared link between a hotel room in Atlanta, Georgia, USA, and Nairobi, Kenya. The VoIP call used an ITU-T G.711 codec, plus proprietary FEC encoding, plus RTP/UDP/IP framing. It received good quality in the presence of packet drop rates of 5-40%.
    • One rule of thumb is that when the packet loss rate exceeds 20%. However, we are not aware of measurement studies of whether VoIP users in practice tend to hang up when packet loss rates exceed some limit.
    • Without the congestion control, a real-time application is likely to significantly increase the risk of Internet congestion collapse, thereby adversely impacting the health of the deployed Internet.
    • The Adaptive Multi-Rate (AMR) codec was chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems.
      • Defined in RFC 3267, it includes forward error correction (FEC) and frame interleaving to increase robustness against packet loss somewhat.
      • The AMR codec supports eight speech encoding modes having bit rates between 4.75 and 12.2 kbps
      • the speech encoding is performed on 20 ms speech frames,
      • it is able to reduce the transmission rate during silence periods.
    • TCP sends fixed-size data packets, and reduces its sending rate in pps when it adapts to network congestion. In contrast, for adaptive VoIP applications, the adaption is sometimes to keep the same sending rate in pps, but to reduce the packet size, reducing the sending rate in Bps. This approach is appropriate when the limitation of the network is in bandwidth in bytes per second (Bps), and not in CPU cycles or in packets per second (pps).
    • the current TCP congestion control mechanisms are themselves not very effective in an environment where there is a limitation along the reverse path in pps.
    • TCP does not include any effective congestion control mechanisms for the stream of small acknowledgement packets on the reverse path.
    • Assuming 40-byte packet headers (IP, RTP, and UDP or DCCP), the application data sending rate of N Bps and M pps translates to a sending rate on the wire of B = N+40M Bps.
    • ECN (Explicit Congestion Notification) allows routers to explicitly notify end-nodes of congestion by ECN-marking instead of dropping packets [RFC3168].

Articles to Read

1. R-value , E-model
2. I-911
3. State Status of PBX E911

topics which you want to learn about VoIP but not covered in this semester

1. VoIP over WLAN
2. Mobile All-IP Network
3. MEGACO 軟體的設定: 怎樣才能與市話相連
4. SIP 軟體的設定: 怎樣才能與市話相連
5. 如何在個人電腦建立小群組，彼此能用 SIP 通話，且市話撥打也能通。
6. 如何架設一台 SIP registrar (與參數設定)
7. VoIP chip design
8. QoS
9. VoIP and SS7
10. Audio I/O
11. RTP Library

Misc

1. Query
2. Reliability
3. P.34 branch of CANCEL
4. P.43 Session version
5. P.44 udp port 45678?
6. NAT traversal
7. Authentication
8. 實習 re-INVITE
9. bandwidth of G.711, G.729
10. STUN/ENUM/MEGACO Lab Hours