SIP and Media Stack Functionality in RTC 1.5
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
RTC is primarily used for real-time communication applications that include Instant Messaging (IM) and Voice over IP (VoIP). Internally, RTC uses standard IETF RFC -based protocols, such as SIP, SDP, RTP, and RTCP.
RTC APIs and Session Initiation Protocol (SIP) changes
In addition to the services and features available in RTC 1.3 with the Window Client RTC API set, we have added several interfaces to RTC 1.5 for the following services:
- Subscription and notification. By using the subscription and notification APIs, you can implement Message Waiting Indication (MWI) and other subscription-based services.** MWI is available as a service with the public VoIP application available in Windows Embedded CE 6.0.**
- Privacy. Using Privacy API, OEMs and users can implement and achieve telephony-strength privacy that includes ID blocking and more.
- Support for PRACK in SIP and support for early media scenarios. With PRACK and provisional acknowledgement support, the OEMs can enable early media scenarios, such as announcements and special ring tones, before the call gets connected.
- Symmetric UDP support on SIP for NAT traversal. RTC 1.5 supports SIP on Symmetric UDP. This helps NAT traversal, especially when dealing with border gateway controllers. To enable NAT traversal, we have enhanced the RTC's Port Manager APIs.
- Port manager API extensions for NAT traversal. Port manager includes API extensions that support NAT traversal, which is used for registration and IM. Port manager is also supported for subscription and notification.
- Enhanced SIP interoperability. We performed extensive testing on RTC’s SIP implementation to ensure its compliance with the SIP RFCs.
RTC Media Stack changes
RTC 1.5 includes a new media stack that has the following audio-related features for VoIP:
- Special audio healing algorithm ensures smooth playback by compensating for various network-related issues with packet loss concealment, jitter control, and comfort noise generation.
- Silence Suppression and Voice Activity Detection help to prevent the non-essential traffic on the network during the prolonged periods of silence. These features are registry-configurable.
- Automatic Gain Control is used to avoid clipping when the sound becomes too weak or too loud.
- Soft Mute functionality. Mute functionality in RTC affects audio related to VOIP calls only. It does not mute other applications' audio playing on the device.
- Registry keys have been added to allow users to disable the internal audio healing with or without pluggable codecs. Because some advanced codecs have their own healing mechanism, or healing is implemented in the hardware, the users can choose to disable the internal audio healer per pluggable codec. An Audio Compression Manager (ACM) -compatible audio codec can be plugged in to the RTC media stack.
- RTC Media stack supports sending and receiving of in-band and out-of-band DTMFs. The duration and time gap between in-band DTMF packets are controllable through registries, to match the resolution of media gateways for in-band DTMF tone detection. For received out-of-band DTMF events, RTC media stack also supports playback of tones. You can disable the playback inside the appropriate registry.
- RTC Media stack supports sending early media, or media that is exchanged before the call is accepted, in the form of both DTMF and voice. This enables you to implement functionality that accepts DTMF tones and also voice commands for controlling interactive voice response (IVR) systems.
- The media stack supports basic NAT traversal techniques by sending and receiving RTP or RTCP packets over symmetric UDP, using a single source port for both types of packets. If a media gateway is present between the caller and the called, which is presently a normal scenario for most of the VoIP service providers, this helps to traverse any type of NAT. As soon as the remote address or port is identified, the media stack also sends the so-called early UDP packets using the RTP/RTCP source port. By helping to "punch" holes through the NAT, the media outside the NAT can get through, thus enabling various early media scenarios.