What’s new in Real time Communication (RTC) 1.5?
Updates to RTC APIs on CE, has been prolonged for some time and there has been many updates to it and thus a blog to cover some high level overview of changes in RTC 1.5:
RTC Overview
RTC is mainly used for real time communication mechanisms like IM, Voice over IP and other real time sharing applications. RTC internally uses standard IETF RFC based protocols like SIP, SDP, RTP, RTCP, etc.
RTC 1.5 Changes
RTC APIs & Session Initiation Protocol (SIP) changes
In addition to service & features of RTC 1.3 of Window Client RTC API set, there has been several interface additions to RTC 1.5, for services like:
1. Subscription/Notification
2. Privacy
3. Support for PRACK in SIP and support for early media scenarios because of that.
4. Symmetric UDP support on SIP for NAT traversal.
5. Port manager API extensions for NAT traversal, for transactions like Registration and IM, which were not supported before. Port manager is also supported for new transactions like Subscribe/Notify
6. Enhanced SIP interoperability
Using Subscription/Notification API, one can implement Message waiting Indication and other subscription based services. MWI is available as a service with the public VOIP app available in Yamazaki.
Using Privacy API, OEM and user can implement and achieve telephony kind of privacy like blocking ID and more.
With PRACK or Provisional acknowledgement support, early media scenarios like announcements or special ring tones, before the call gets connected can be enabled.
RTC 1.5 now supports SIP on Symmetric UDP. This helps NAT traversal, especially when dealing with border gateway controllers. There have been enhancements to Port Manager APIs of RTC as well to enable NAT traversal.
RTC Media Stack changes
Internally, there is a completely new media stack. The new media stack has following audio related features for VOIP:
- Audio Healing – Smooth playback (like packet loss concealment, jitter control, etc)
- Silence Suppression.
- Voice Activity Detection
- Comfort Noise Generation
- Automatic Gain Control to avoid clipping and when sound is too low.
- Soft Mute functionality
- Support for built-in and pluggable codecs
- DTMF Events (OOB and InBand)
The new media stack has silence suppression logic and voice activity detection built-in to avoid unnecessary traffic on the network for prolonged silence periods. These features are registry configurable.
The new media stack uses a special audio healing algorithm to compensate for network related issues like packet losses, jitter, comfort noise generation on the audio receiver end, etc.
The pluggable audio architecture is the same as I CE RTC 1.2 . An ACM compatible audio codec can be plugged in to the RTC media stack. We have added registry keys to let user choose whether internal audio healing should be used with pluggable codecs or not. This is because some advanced codec may have their own healing mechanism or the healing might be done in hardware or some other mechanism and hence the user may choose to disable the internal audio healer per pluggable codec.
RTC Media stack supports sending & receiving of in-band and out of band( OOB) DTMFs. The duration & time gap between in-band DTMF packets are controllable through registries to match the resolution of media gateways for in-band DTMF tone detection. RTC media stack also supports playback of tones, for received OOB DTMF events. The playback can be disabled using a registry if desired.
The Media stack also supports basic NAT traversal techniques by sending & receiving RTP/RTCP packets over symmetric UDP. This means that it sends & receives RTP packet using a single source port, and same for RTCP. This helps traversing any type of NAT, if a media gateway is present in between the caller & the callee, which is a normal scenario for most of the VOIP service providers these days.
The media stack also sends “early” UDP packets using RTP/RTCP source port, as soon as the remote address/port is learnt. This helps in “punching” holes through the NAT, which enables receiving of media from outside the NAT, thus enabling early media kind of scenarios.