Voice over IP

Chapter 1 Introduction 9/19
Chapter 2 Transporting Voice By Using IP , Introduction to IETF
Homework 1 Due:
Chapter 5 Session Initiation Protocol (SIP) 10/23-10/30
Lab: SIP UAs and SIP Analyzer ; RTP Monitor 11/6
SIP Lab Hour 11/13
Mid-term 11/20
陳柏州, 王鐘逸 11/27
張兢真, 施賢孝 12/4
施賢孝, 張文萍 12/11
黃育成, 陳柏志 12/18
陳冠榮, 李宗儒 12/25
開國紀念日, 依行事曆放假一天 1/1
NAT Traversal 1/8
Final Exam 1/15

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 Scoring
Correctness 80%
Related Reference 10%
Examples 10%

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)
  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 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) (李宗儒)
  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

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


  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