Windows CE Networking Team WebLog : Real Time Communication

Inspect incoming SIP headers in RTC CE 6.0 R2 release

cenet — Tue, 13 May 2008 22:22:00 GMT

There are many scenarios where inspecting incoming SIP messages for custom headers is useful. Many servers add their custom headers for custom functionalities like custom ring tones, shared line functionality, privacy, etc. and hence having the ability to inspect incoming SIP messages is very useful. In CE 6.0 R2 release, RTC supports the capability of inspecting incoming SIP messages.

The incoming SIP messages that can be inspected are those that generate an RTC EVENT. All Event interfaces can now be queried for the interface: IRTCSIPEvent, which exposes the following g API:

HRESULT GetSIPMessage(

[out] IRTCSIPMessage ** ppMessage

);

If the event indeed was generated because of an incoming SIP message, then the above API will return a valid IRTCSIPMessage interface, else the error RTC_E_NO_SIP_MESSAGE will be returned and the incoming pointer will be set to NULL in that case.

Interfaces that can be queried for IRTCSIPEvent are:

IRTCRegistrationStateChangeEvent

IRTCSessionStateChangeEvent

IRTCSessionOperationCompleteEvent

IRTCMessagingEvent

IRTCInfoEvent

IRTCReInviteEvent

IRTCSessionReferStatusEvent

IRTCSessionReferredEvent

IRTCSubscriptionStateChangeEvent

IRTCSubscriptionNotificationEvent

IRTCUnsolicitedNotificationEvent

IRTCSessionConsultantReferredEvent

IRTCSessionNotificationEvent

A few examples of cases where RTC events are generated due to incoming SIP messages and for which, those incoming SIP messages can be inspected are:

1. REGISTRATION success, registration failure response from the server, etc.

2. Incoming INVITEs for different types of RTC sessions, incoming INFO, MESSAGE types

3. Incoming PRACK messages

4. Incoming notifications for subscriptions

5. Etc.

Adding custom SIP headers using RTC, in CE 6.0 R2 release.

cenet — Tue, 13 May 2008 18:09:00 GMT

Adding custom SIP headers using RTC, in CE 6.0 R2 release.

In CE 6.0 R2, RTC now supports the capability of adding custom headers to outgoing REQUEST messages, for RTC sessions and RTC subscriptions. Here is how once can do it.

After CE 6.0 R2 release, IRTCSession interface and IRTCSubscription can now be queried for the interface: IRTCSIPObject. This interface supports the following 2 functions:

HRESULT SetAdditionalHeaderValues(

[in] BSTR bstrHeaderValuePairs

);

HRESULT GetAdditionalHeaderValues(

[out] BSTR* pbstrHeaderValuePairs

);

SetAdditionalHeaderValues function can be used to add additional custom headers to outgoing REQUEST style messages, of the IRTCSession and IRTCSubscription, on which it gets called.

So, in case of IRTCSession, those messages would be:

INVITE, PRACK(in case PRACK is supported) and final ACK during session setup or mid –session(for cases like Hold).

CANCEL or BYE message when the session is cancelled or terminated.

In case of IRTCSubscription, the message will be SUBCRIBE.

To stop sending custom headers, SetAdditionalHeaderValues can be called again with a NULL value.

GetAdditionalHeaderValues API can be used to get back the header pair value string that is set by the SetAdditionalHeaderValues API.

Note: These APIs give direct control in modifying outgoing SIP messages and hence should be used with “extreme” caution. RTC does not validate the contents of the custom headers added, nor does it check the format of these custom headers. Adding improper custom header values can cause the remote side of the RTC session or subscription to reject SIP messages, which can lead to unexpected application behavior.

Controlling VOIP interfaces on Windows Mobile devices

cenet — Wed, 16 Jan 2008 23:43:00 GMT

RTC 1.5 can be restricted to use only certain types of interfaces (Wifi, Ethernet, etc.) on Windows Mobile devices. Same restriction cannot be applied on Windows CE, as RTC uses connection manager functionality to do that, which is not available on Windows CE.

RTC can be restricted using the following reg keys. These reg keys need to be set before RTC gets initialized.

HKLM\Comm\RTC\AdapterTypes

One can list all the allowed interfaces as numerical keys:

e.g. 1

ETC.

The value of each key should be an ORed value of the connection manager interface type and sub-type

e.g. If one wants to allow Ethernet interface only.

The connection manager interface type to use will be CM_CONNTYPE_NIC (0x2)

The connection manager sub-interface type to use will be CM_CONNSUBTYPE_NIC_ETHERNET (0x1)

The Ored value = (0x2 << 16) | 0x1 = 0x20001

So the reg key will look like:

HKLM\Comm\RTC\AdapterTypes\1 (DWORD with value 0x2001)

Similarly, if Wifi is also desired,

The connection manager interface type to use will be CM_CONNTYPE_NIC (0x2)

The connection manager sub-interface type to use will be CM_CONNSUBTYPE_NIC_WIFI (0x2)

The ored value = 0x2 << 16 | 0x2 = 0x20002

So the reg keys will look like:

HKLM\Comm\RTC\AdapterTypes\1 (DWORD with value 0x2001) ß for Ethernet

2(DWORD with value 0x2002) ß For Wifi

Pluggable video codec for RTC 1.5 stack

cenet — Tue, 15 Jan 2008 02:45:00 GMT

RTC 1.5 (CE 6.0 R 2 release) supports Point to Point Video calling. However, the stack does not ship any built-in video codecs. Instead it supports a pluggable video codec architecture through which, one can add their own video codecs.

Below are the steps one needs to take to plug-in a video codec into the RTC stack.

1. Implement your video codec in form of a DShow filter. Here is a MSDN link that explains How to write a DShow filter.

2. On the device, set the following reg keys before RTC is initialized:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

*Note: <key set#> can be any name (e.g. 1,2,3 or codec name itself)

*Note: For latest and up to date pluggable video codec reg keys listed below, please visit the MSDN link here .

Name	Type	Description
EncoderFilter	REG_SZ	Specifies the COM CLSID of the encoding IBaseFilter.
DecoderFilter	REG_SZ	Specifies the COM CLSID of the decoding IBaseFilter.
DecoderMediaSubtype	REG_SZ	Specifies the media subtype GUID of the format of the incoming data. Examples of incoming data format include H263 and H264.
CodecType	REG_SZ	Specifies the codec type. Always set the data to `Filter`. There is no default value.
CodecRank	REG_DWORD	Sets the relative priority of the codec. The data is an integer between 0 and 100. The highest priority is 0 and the lowest is 100.
CodecName	REG_SZ	Specifies the name of the codec sent in the Session Description Protocol (SDP) payload. For example, the codec name could be `H263-1998`. The name must contain fewer than 32 characters.
PayloadType	REG_DWORD	Specifies the RTP payload type associated with the codec. For example …
ClockRate	REG_DWORD	Indicates the clock rate of the codec as it appears in the `a=rtpmap` line of the SDP . For many codecs the correct data is 90,000.

Note: If a codec needs to be represented by multiple payload types (as some codec do), then a separate key set needs to be added for each payload type. RTC supports plugging in a maximum of 7 such key sets (7 separate payload types).

3. If your codec supports custom codec properties, which needs to be negotiated through SDP using FMTP lines, then the codec can put its FMTP string in the following reg key:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

Name

Type

Description

SDPFmtp

REG_SZ

Indicates the format specific parameters FMTP of the codec as it appears in the SDP a=fmtp line of the SDP. If SDPFmtp is not set, no FMTP lines will be sent.

This data indicates only the parameters themselves. SDP automatically fills in the following text:a=fmtp:<RTP Payload Type #>

RTC will read the reg key during initialization, and will add it to the outgoing SDP as is, as FMTP properties of the codec. If no reg key is specified, no FMTP lines will get published in SDP for the codec.

4. RTC also supports passing of incoming FMTP property string to the plugged in codec, so that the codec can make a decision if it supports those properties or not. The pluggable codec needs to implement the following interface: IRTCSDPValidator to accept incoming FMTP strings from the SDP. The following reg keys needs to be set for the codec, to let RTC know of the interface:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\SdpValidators

Name	Type	Description
<Codec Name>	REG_SZ	Specifies the CLSID that implements this object.

e.g.

Name	Description
H263-1998	{D018239F-4022-4c15-BC87-03CCADC1A4E3}

Note: An IRTCSDPValidator registry value is not required. If a codec does not implement this registry key, the codec accepts all SDP.

5. Implement interfaces that allow adding and removing custom RTP headers.

RTC uses RTP as the media transport protocol for video. RTP allows adding codec specific headers for each RTP payload. Since this header is codec specific, RTC provides a mechanism so that pluggable codecs can add/remove these custom RTP headers during the encode/decode process.

Implement the interface IRTCPluggableVideoEncoder to add custom RTP header and the interface IRTCPluggableVideoDecoder to remove custom RTP headers. Publish these interfaces in the reg key:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

Name	Type	Description
EncoderPlugin	REG_SZ	Specifies the COM CLSID of the IRTCPluggableVideoEncoder interface. Set H.263 to {A7D8A6EF-575B-4750-A727-04234A70D9DE} to use the Microsoft provided implementation of this interface. Set H.264 to {92A200F8-0981-11DC-813E-B77255D89593} to use the Microsoft provided implementation of this interface.
DecoderPlugin	REG_SZ	Specifies the COM CLSID of the IRTCPluggableVideoDecoder interface. Set H.263 to {0CE193DF-27F0-48c7-92F7-75CA7A5965E6} to use the Microsoft provided implementation of this interface. Set H.264 to {86546C00-0981-11DC-88BE-AE7255D89593} to use the Microsoft provided implementation of this interface.

*Note: The Microsoft implementation of the above interfaces for H263 and H264 video codecs can be found at CE OS installation location: public\fp_voip\oak\codecs\H263Parse and public\fp_voip\oak\codecs\H264Parse respectively.

Now that we know how to write a pluggable video codec and add it to RTC, let’s see how RTC will use the codec and all other interfaces by the codec module:

1. As soon as RTCClient object is initialized, RTC goes through the all reg keys defined above to check for any pluggable video codecs. If the reg keys are set, RTC will check, verify and load the codec for future use.

2. When a user makes an outgoing video using RTC, then:

a. All pluggable video codecs that are successfully loaded by RTC, will get published in the outgoing SDP.

b. If the codec has set the SDPFmtp reg key to specify its FMTP properties, then RTC will add that string in the outgoing SDP for the respective video codec.

3. When an incoming video call is received by RTC, then:

a. For each video codec published in the incoming SDP, RTC will try to match it with its plugged in codecs. If any of the codec name matches, then RTC checks to see if the codec implements IRTCSDPValidator interface. If it does, then RTC will call the CheckAcceptableFmtp function of the interface with the incoming FMTP string, to let the codec check if it can support those properties. If the function returns S_OK, RTC considers that codec is capable of handling the incoming FMTP properties, and it proceeds with the call as usual. Any other return value is considered a failure. If there is no codec match, RTC will reject the call.

b. If the codec does not implement IRTCSDPValidator, then RTC assumes that the codec is capable of handling any incoming FMTP property, and will proceed with the call as usual (generally by triggering an event of an incoming video call)

4. Once the call has been established:

a. During the encode process, RTC will call the appropriate filter APIs to encode the raw video frames. After that, RTC will call the IRTCPluggableVideoEncoder interface API to let the codec generate custom RTP header for the encoded frame. Please see the MSDN page for more details on the interface.

b. During the decode process, RTC will first call the IRTCPluggableVideoDecoder interface API to let the interface extract the encoded frame from RTP payload. Once an entire encoded frame is extracted, RTC will then call the filter APIs to decode the raw video frames. Please see the MSDN page for more details on the interface.

Sample Code for Local Audio Mixing using RTC 1.5 (CE 6.0 R2 Release)

cenet — Thu, 10 Jan 2008 03:26:00 GMT

Sample code for local audio mixing to achieve 3 way/N way calling.

In CE 6.0 R2 release, RTC 1.5 started supporting local audio mixing. Local audio mixing can be enabled by using the flag RTCIF_ENABLE_GLOBAL_MEDIA_MIXING during RTCClient object initialization. Here is the code example (ignoring error handling):

Initialize RTC to enable local media mixing:

hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);

hr = CoCreateInstance(CLSID_RTCClient,

NULL,

CLSCTX_INPROC_SERVER,

IID_IRTCClient,

(LPVOID *)&gpRTCClient );

IRTCClient2 *piRTC2 = NULL;

hr = gpRTCClient->QueryInterface(IID_IRTCClient2, (void**)&piRTC2);

hr = piRTC2->InitializeEx(RTCIF_ENABLE_GLOBAL_MEDIA_MIXING);

Once media mixing is enabled, audio for all calls will be locally mixed. Consider the following example to see how 3-way /N way calling can be achieved:

Consider two audio calls between a caller (Endpoint 1) and two other callers (Endpoint 2 and 3). Without local media mixing, 2 and 3 can talk to 1, but not to each other on the existing calls. When local audio mixing is enabled on endpoint 1, endpoint 1 mixes the audio stream as described below, which will enable 3-way conferencing, and all three can talk to each other.

· Endpoint 1 mixes its own audio (1) with the audio that it receives from endpoint 3 (3) and sends it to endpoint 2. Similarly,

· Endpoint 1 mixes its own audio (1) with the audio that it receives from endpoint 2 (2) and send it to endpoint 3.

This way, endpoint 2 can listen to endpoint 3, and endpoint 3 can also listen to endpoint 2.

Since Endpoint 1 is the mixer, the conferencing is dependent on endpoint 1. If endpoint 1 disconnects any of the calls, then Endpoint 2& 3 won’t be able to talk to each other.

Here is a code example (ignoring error conditions for simplicity)

Establishing a 3 way call:

Step 1: Endpoint 1 Calling Endpoint 2

hr = gpRTCClient->CreateSession(RTCST_PC_TO_PC, NULL, NULL, 0, &pSessionEndpoint2);

if (SUCCEEDED(hr))

{

hr = pSessionEndpoint2->AddParticipant(bstrEndpoint2URI, bstrEndpoint2Name, NULL);

}

After this, RTC will post a session connected event, once the call has been established between endpoin1 and endpoint 3.

Step 2: Endpoint 1 putting Endpoint 2 on Hold, before calling Endpoint 3

IRTCSessionCallControl* pSessionEndpoint2CallCtrl = NULL;

// Query for the IRTCSessionCallControl interface.

HRESULT hr = pSessionEndpoint2->QueryInterface (IID_IRTCSessionCallControl,

(void**) & pSessionEndpoint2CallCtrl);

hr = pSessionEndpoint2->get_State(&enState);

if(enState != RTCSS_CONNECTED)

{

ASSERT(0);

// Handle error!!

}

pSessionEndpoint2CallCtrl->Hold(lCookie);

Step 3: Endpoint 1 Calling Endpoint 3

hr = gpRTCClient->CreateSession(RTCST_PC_TO_PC, NULL, NULL, 0, &pSessionEndpoint3);

if (SUCCEEDED(hr))

{

hr = pSessionEndpoint3->AddParticipant(bstrEndpoint3URI, bstrEndpoint3Name, NULL);

}

Step 4: Endpoint 1 Unholds Endpoint 2 to establish 3 way conference

IRTCSessionCallControl* pSessionEndpoint2CallCtrl = NULL;

// Query for the IRTCSessionCallControl interface.

HRESULT hr = pSessionEndpoint2->QueryInterface (IID_IRTCSessionCallControl,

(void**) & pSessionEndpoint2CallCtrl);

hr = pSessionEndpoint2->get_State(&enState);

if(enState != RTCSS_HOLD)

{

ASSERT(0);

// Handle error!!

}

pSessionEndpoint2CallCtrl->UnHold(lCookie);

After Step 4, all 3 endpoints can talk to each other. Please note that Step 2 and Step 4 (putting Endpoint 1 call on Hold and then UnHold) are optional steps. RTC 1.5 will allow making call to Endpoint 3 while call to Endpoint 2 is active. But this kind of calling is not normal in the telephony world.

If Endpoint 1 wants to talk to Endpoint 2 exclusively, it can simply put Endpoint 3 call on Hold, and similarly it can put Endpoint 1 call on Hold if it wants to talk to Endpoint 3 exclusively.

Also note that even though media is mixed for both calls, All APIs related to each call (like RTCSession and RTCParticipant APIs) will only act on the respective individual calls. For e.g.

Example 1: pSessionEndpoint2->Terminate(RTC_TERMINATE_REASON) will just disconnect Endpoint 2 and not Endpoint 3.

Example 2: pPartEndpoint2->SendDTMF(RTC_DTMF) will send DTMF tones only to Endpoint 2, and not to Endpoint 3,

etc.

However, APIs like CRTCClient::put_Volume(RTC_AUDIO_DEVICE enDevice, long lVolume) will affect both calls.

Thanks and happy coding!!

What is new in RTC 6.0 R2 release?

cenet — Wed, 09 Jan 2008 02:10:00 GMT

Following are the new features in RTC 6.0 R2 release:

1. Local audio mixing capability (enabling 3 way VOIP calling)
2. Point to Point Video Calls
3. Pluggable Video Codec capability
4. Ability to inspect SIP headers for certain SIP messages
5. Ability to add custom headers to certain outgoing SIP Messages
6. Attended Call Transfer facility
7. Call Park/Pickup facility

All the above features, except video, are available through VOIP default sysgen, i.e. SYSGEN_VOIP. Point to Point Video

feature is selectable using SYSGEN_VOIP_VIDEO sysgen.

As time permits, I and my team will blog out each feature in more details.

For now, you can get some details about local audio mixing through the following link:
http://download.microsoft.com/download/0/7/4/0748b074-ed6c-461f-bcd0-e35d047bc1f8/Windows%20Embedded%20CE%206.0%20R2%20Release%20Notes.htm#WN7

Thanks and happy new year to all!!
Rajesh

RTC's VOIP delay

cenet — Thu, 07 Jun 2007 10:09:00 GMT

This blog explains the different components that contribute to the audio delay in a VOIP call, and then discusses RTC's VOIP delay numbers.

When any VOIP call made between any 2 VOIP entities, the end-to-end delay for the VOIP call can be categorized as following:

a. VOIP Sender side delay

b. Propagation delay on the wire between 2 VOIP entities.

c. VOIP receiver side delay

Since our focus is delay characteristics of a device running RTC, let's ignore the propagation delay for now.

On VOIP sender side, the following component contributes to delay in general:

1. Audio Driver capture delay.

2. VOIP stack send delay (RTC media stack send delay)

3. (OS network + network driver) send delay

On VOIP receiver side, the following component contributes to the delay:

4. (OS network + network driver) receive delay

5. VOIP stack receive delay (RTC media stack send delay)

6. Audio Driver playback delay

As you can see, besides VOIP (RTC) stack delay, the end-to-end delay is also dependent on the network driver as well as the audio driver of the devices, which can vary from device to device.

Let us now look at RTC numbers with respect to the above categories.

For RTC, when a peer-to-peer VOIP call is made between 2 CEPCs (x86 machines running CE) sitting side-by-side in a lab, and using G711 codec, the total end-to-end delay measured was around 70msec.

RTC’s send delay (i.e. time spent by an audio packet within RTC media stack only, after RTC receives it from the waveIn and just before RTC submits the packet to socket layer to transmit over the wire) was measured around 2 to 3 msec

RTC’s receive delay (i.e. time spent by an audio packet within RTC media stack only, after RTC receives it from the socket layer and just before it submits the packet to wave API layer to play) is around 35 to 38 msec. The receive delay is more because RTC has an audio healer algorithm to dejitter and heal received audio data.

So the total RTC delay (send + receive) is around 38 to 40 msec.

The rest of the time (70 – 40 = 30 msec) is spent in the network + audio driver.

Since a human ear can tolerate a delay of around 200 mec, there is plenty of room for propagation delay.

How to make RTC VOIP functionality work with Vonage?

cenet — Wed, 30 May 2007 09:19:00 GMT

RTC uses standard based SIP signaling and RTP/RTCP media streams to provide VOIP functionality. To verify this, I carried out a little experiment to see if RTC works with existing VOIP services like Vonage. Guess what? It did :).

Here are the steps to configure RTC to make it work with Vonage. Please note that these are trial & error steps and the experiment was mainly to validate RTC's implementation with a consumer VOIP service. I tried this in 2006 and hence these steps may change if Vonage changed its configuration (server address/port, authentication, transport protocol, etc.) since then:

1. Use your Vonage client account information to create the RTC profile. Here is the sample profile that I used:

<user name = 'Vonage User' account='<11 digit phone number>' password='<password>' uri='sip:<11 digit phone number>@216.115.20.41' allowedauth='digest'/>

</sipsrv>

</provision>

Fill in <11 digit phone number> and <password> with the information that you have from Vonage.

216.115.20.41 is the Vonage proxy/registrar server address that I saw was being used for my account. Verify if this is still valid or if you have a DNS name for the Vonage server, put that info instead of the IP address.

2. Use UDP as the transport protocol (Set in the profile above)

3. Use symmetric UDP for SIP signaling. i.e. During RTC initialization, use the following initialization RTC flag: RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING

a. Use static local source port (5060) to listen to all incoming request i.e. During RTC initialization, use the following flag during initialization: RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP

4. Used digest as authentication protocol (Set in the profile above)

5. Use server destination port as 5061 (Set in the profile above)

And Voila! RTC works with Vonage. I experimented before and after NAT case and it worked for both.

Please note: The above test was a pure proof of concept, to test RTC's standardized SIP implementation withh existing services like Vonage. The scenario is neither officially supported by Microsoft nor Vonage.

Real Time Communication (RTC) support on CE and Windows Mobile platforms

cenet — Wed, 23 May 2007 21:03:00 GMT

There were many queries about using RTC on Windows Mobile platform. With this blog, I will try to clarify on which platforms RTC is available and supported.

So far, RTC has always shipped as a part of the general embedded CE release. It is supported as a part of CE releases only. Until WM6, RTC was never available on Windows Mobile platform. Copying CE released binaries on Windows Mobile is unsupported. There may also be licensing issues with that.
On some Windows Mobile 6 SKUs, VOIP (Voice over IP) is supported. This functionality is based on RTC. So, RTCDll.dll (RTC binary) will be available on some of the WM 6 SKUs. However, on these SKUs, RTC is not released as an SDK, but solely to provide the VOIP functionality. So if an application wishes to use RTC on these SKUs, it is free to do so, but that scenario won’t be supported by Microsoft.

Hope this will clarify some questions around RTC support on CE as well as Windows Mobile platforms.

- Rajesh

RTC 1.5 Useful registry Keys

cenet — Sat, 09 Dec 2006 07:41:00 GMT

RTC Core Layer and SIP protocol keys

Port manager related keys

Key Path:

HKLM\Comm\\RTC\\PortRange

Key Value(s)	Key Value Type	Description
Enabled	DWORD	Enables Port range as defined by subsequent port key values
MinSipDynamicPort MaxSipDynamicPort	DWORD	Used for setting the port range for SIP signaling traffic.
MinMediaPort MaxMediaPort	DWORD	Used for setting the port range for audio/video RTP and RTCP traffic.

Qos Related Keys

Key Path:

HKLM\Comm\\RTC\\QoS

Key Value(s)	Key Value Type	Description
Disabled	DWORD	When = 1, disables setting of DSCP field in IP header and layer 2 tagging. By default DSCP QoS is On
DSCPSIP	DWORD	Defines the DSCP index value to be used for SIP packets. By default, DSCPAudio (index 5) is used. DSCPAudio corresponds to 0x38 in IP DSCP/TOS field.

SIP protocol related keys

Key Path:

HKLM\Comm\\RTC

Key Value(s)

Key Value Type

Description

MinExpiresTimeoutinSec

DWORD

Lets user set the minimum expiry time in sec, that is allowable by RTC. Any value lower than the value set in this registry (or default 19 sec when not set) from the server will be rejected.

The registry is settable in the range of 5 to 9999999

Media Stack

Devices

Key path:

HKLM\Comm\RTC\DeviceSettings

Key Value(s)	Key Value Type	Description
DeviceSSMode	DWORD	If set to 0, will disable silence suppression and all audio packets, including silence will be transmitted during an audio call.
DeviceAudioSamplingFrequency	DWORD	Should be set either to 8000 or 16000. This registry lets the devices to be opened either using 8K or 16K sampling frequency. By default devices are opened at 8K sampling frequency. Opening devices at 16K will cause increase in network bandwidth as more audio samples are sent over the network. CPU consumption also increases as more samples are processed by the media stack and AEC module (if enabled). However, audio quality also increases when 16K samples are used.
DisableAGC	DWORD	If set to 1, it disables AGC (Auto Gain Control in RTC)

Media Stack Performance Tuning

Key path:

HKLM\Comm\RTC\Threads

Key Value(s)	Key Value Type	Description
EngineThreadsPriority	DWORD	Lets user change the priority at which media stack thread is running (default is 221). Acceptable value is between 1 and 255. Caution should be used in changing the default priority as this may impact the way audio data is captured and rendered and may also affect other components running on the system.
TimerFrequency	DWORD	Lets user set the polling time period for the RTC media engine stack. Default is set to 5 msec (value 50000). Registry is settable between values 10000 (1 msec) and 1000000 (100 msec)
OverlappedSend	DWORD	If set to 0, will disable overlappedSend and used blocking send for WinSock sockets. This may increase processing time of the media stack thread.
TransportThreadsPriority	DWORD	Lets user change the priority at which media stack transport thread is running (default is 221). Acceptable value is between 1 and 255. Caution should be used in changing the default priority as this may impact the way media data is processed and may also affect other components running on the system.

Media Stack QoS

Key path:

HKLM\Comm\RTC\QoS

Key Value(s)	Key Value Type	Description
Disabled	DWORD	When = 1, disables setting of DSCP field in IP header and layer 2 tagging. By default DSCP QoS is On
DSCPAudioRTP	DWORD	Defines the DSCP index value to be used for Audio RTP packets. By default, DSCPAudio (index 5) is used. DSCPAudio corresponds to 0x38 in IP DSCP/TOS field.
DSCPAudioRTCP	DWORD	Defines the DSCP index value to be used for Audio RTCP packets. By default, DSCPAudio (index 5) is used. DSCPAudio corresponds to 0x38 in IP DSCP/TOS field.

Media Stack NAT work around

Key path:

HKLM\Comm\RTC\NAT

Key Value(s)	Key Value Type	Description
EnableEarlyUDPPackets	DWORD	When set to 1, enables sending Early UDP packets on RTP and RTCP ports, whenever RTC stack detects a change in remote address/port. This enables opening of ports on a NAT, incase RTC client is behind one. This way, traffic from the remote client can be received through the NAT.

Media Stack in-band DTMF

Key path:

HKLM\Comm\RTC\DTMF

Key Value(s)	Key Value Type	Description
InBandDTMFToneGap	DWORD	This lets user set the time gap that RTC should introduce between sending 2 in-band DTMF tones. The default value is 250msec and the reg key is settable in msec between 100 and 1000.
DisableOOBDTMFPlayback	DWORD	This lets user disable playback of Out of Band DTMF events. By default, RTC media stack plays back these events with the corresponding DTMF tones
OOBDTMFPlaybackDuration	DWORD	This key controls the duration of the OOB DTMF tone playback. This accepts value between 10 and 500 msec. By default, tones played back are of 200 msec.

Media Stack Pluggable Codec

Key path:

HKLM\Comm\RTC\Codec

Key Value(s)	Key Value Type	Description
UseSirenAndG7221	DWORD	Activates use of Siren and G7221 codec inside of RTC. By default, these 2 codecs are turned off as they are floating point based and may not be suitable for ARM based devices.
UsePreferredCodec	DWORD	If set to 1, it enables preferred codec logic. A codec can be made preferred by setting this key and setting the reg key PreferredAudioCodec to the payload number of the codec, that needs to be made preferred
PreferredAudioCodec	DWORD	If set to a codec payload number, along with setting UsePreferredCodec to 1, makes the respective codec as the preferred codec. This ensures that RTC will select the respective codec over other codecs, if the remote party supports the preferred codec. Setting this key also causes RTC to list that codec as the first codec, in the SDP.

Key path:

HKLM\Comm\RTC\ ACM

Key Value(s)

Key Value Type

Description

Sub-Key

Each key Under HKLM\Comm\RTC\ACM

Denotes a pluggable codec e.g.

HKLM\Comm\RTC\ACM\GSM can be used for GSM610 codec.

Key path:

HKLM\Comm\RTC\ACM\<Codec Name>

Key Value(s)	Key Value Type	Description
PayloadType	DWORD	Denotes playload type
FrameDuration	DWORD	Denotes frame duration in msec
CodecRank	DWORD	Denotes the rank of the codec
UseHealer	DWORD	Indicates weather internal RTC audio healing should be used for this codec or not. By default it is not used.
Driver	String	Indicates the dll name that implements the codec.

Key path:

HKEY_LOCAL_MACHINE\Comm\RTC\ACM\<Codec Name>\WaveFormat

Key Value(s)	Key Value Type	Description
FormatTag	DWORD	Denotes format tag
Channels	DWORD	Number of channels that the codec supports.
SamplesPerSec	DWORD	Denotes samples per sec that the codec supports.
AvgBytesPerSec	DWORD	Denotes Avg. Bytes per sec
BlockAlign	DWORD	Block Align
BitsPerSample	DWORD	Bite Per Sample
bSize	DWORD

Corrections to CE RTC 1.5 documentation on MSDN

cenet — Sun, 26 Nov 2006 03:54:00 GMT

There has been several documentation errors related to RTC 1.5 on MSDN. Here are a few of them:

Issue 1:

http://msdn2.microsoft.com/en-us/library/aa924993.aspx

The following page mentions that RTC 1.5 supports multi party audio/video and application sessions. This is incorrect. RTC 1.5 does not support multi-party audio/video and application sessions. It supports only single party sessions. RTC 1.5 does not support Video communication at all.

Issue 2:

http://msdn2.microsoft.com/en-us/library/aa921850.aspx

This page is confusing and it simply re-enlists all enumeration changes in RTC, between CE 4.2 and CE 5.0

Issue 3:

http://msdn2.microsoft.com/en-us/library/aa921714.aspx

This page shows a list of RTC version releases in various CE releases. This page does contain CE 6.0 and the corresponding RTC 1.5 release in CE 6.0.

Issue 4:

http://msdn2.microsoft.com/en-us/library/aa926591.aspx

This page is incomplete in its contents. It is supposed to enlist all RTC registries but it does not. (Please wait for my next blog which will list all RTC registries)

Issue 5:

http://msdn2.microsoft.com/en-us/library/aa924743.aspx

The title of this section is confusing. There is no such thing called “Extensibility APIs” in RTC. This section is supposed to list all new interfaces added in RTC 1.5. This section does not list all the new interfaces that were added. I or my team members will slowly blog all the interfaces that were added in RTC 1.5 and are not listed in this section, until MSDN content is updated.

Issue 6:

http://msdn2.microsoft.com/en-us/library/aa925753.aspx

The RTC API reference in CE 6.0 does not contain all the interfaces that were added in RTC 1.5. Some of the interfaces that were added in RTC 15, are listed at http://msdn2.microsoft.com/en-us/library/aa924743.aspx

Issue 7:

http://msdn2.microsoft.com/en-us/library/aa924927.aspx

This section contains a page on traversing UPNP based NATs (http://msdn2.microsoft.com/en-us/library/aa926570.aspx). However, RTC 1.5 removed support for UPNP based NATs. Instead, it enhanced it’s port manager APIs and also added support for symmetric UDP/TCP to better traversal of NATs.

Issue 8:

http://msdn2.microsoft.com/en-us/library/aa921657.aspx

This page needs to be updated to reflect the latest port manager interfaces in RTC 1.5

Issue 9:

http://msdn2.microsoft.com/en-us/library/aa922890.aspx

The Voice performance section is outdated. The new media stack in RTC 1.5 does not rely on audio driver firing interrupts, whenever an audio capture packet is available. Instead the media stack now polls if an audio capture packet is available. RTC media stack checks if WHDR_DONE is set for any submitted capture wave headers.

Issue 10:

http://msdn2.microsoft.com/en-us/library/aa923483.aspx

This page compares Windows Client RTC with Window CE RTC. This page needs to be updated as CE has released RTC 1.5, whereas Windows Client has not.

Issue 11:

http://msdn2.microsoft.com/en-us/library/aa921895.aspx

This page content is supposed to provide information on Session Types that RTC supports. The Session Type column in the table does not list proper Session types. Please see Windows Client’s Session Information for correct information:

http://msdn2.microsoft.com/en-us/library/ms775982.aspx

Issue 12:

http://msdn2.microsoft.com/en-us/library/aa923400.aspx

The following catalog items for RTC are not supported in Windows CE 6.0

SYSGEN_VOIP_MEDIA_AEC

SYSGEN_VOIP_MEDIA_RTAUDIO

Also, SYSGEN_VOIP_MEDIA is not user settable. It gets set, when SYSGEN_VOIP is set.

SYSGEN_VOIP_SIGNALING should be used instead of SYSGEN_VOIP, if user intends to use only the signaling portion of RTC (rtcdll.dll) and disable RTC’s media stack and deselect RTC’s media stack dll. (rtcdllmedia.dll)

Quality of Service in RTC 1.5

cenet — Fri, 17 Nov 2006 03:23:00 GMT

RTC 1.5 supports quality of service for SIP & audio packets using DSCP and 802.1Q tagging. Windows CE has the following pre-defined DSCP traffic types:

typedef enum _DSCP_TRAFFIC_TYPE {
    DSCPTypeNotSet        = 0,
    DSCPBestEffort        = 1,
    DSCPBackground        = 2,
    DSCPExcellentEffort   = 3,
    DSCPVideo             = 4,
    DSCPAudio             = 5,
    DSCPControl           = 6,
    NumDSCPTrafficTypes   = 6
} DSCP_TRAFFIC_TYPE

Check the following link for more info on these traffic types.

http://msdn2.microsoft.com/en-us/library/aa916382.aspx

By default, RTC uses DSCPAudio traffic type for audio RTP, RTCP and SIP packets.

RTC defines registry keys if user wants to use alternate traffic types for RTP, RTCP or SIP packets. The reg keys are as follows:

HKLM\Comm\RTC\QoS

DSCPAudioRTP - (DWORD)To change traffic type for Audio RTP packets. Settable to the DSCP enumeration value (0 to 6)
DSCPAudioRTCP - (DWORD)To change traffic type for Audio RTCP packets. Settable to the DSCP enumeration value (0 to 6)
DSCPSIP - (DWORD)To change traffic type for SIP packets. Settable to the DSCP enumeration value (0 to 6)

By setting these traffic types, the DSCP field in the IP header get set to the values that correspond to these traffic types. The DSCP values that go in the header for the above defined traffic types are:

{ 0x00, 0x00, 0x08, 0x18, 0x28, 0x38, 0x38 };

These traffic types also get translated to appropriate 801Q mapping, at layer 2, if the layer underneath supports such a tagging.

User can also disable the whole QOS tagging by setting the following reg

key:
HKLM\Comm\RTC\QoS

Disabled - (DWORD). If set to 1, RTC Qos will be disabled.

Completing RTC's NAT story

cenet — Mon, 13 Nov 2006 10:33:00 GMT

In my first post, I touched on all the new features of RTC 1.5. Prathap also posted a blog on RTC 1.5 port manager, which shows how RTC's port manager APIs can be used by user app to communicate outside NAT. Here I will try to complete the NAT picture of RTC 1.5

As mentioned in my first blog, RTC supports the following features for NAT traversal:

1. Port manager APIs (covered by Prathap's' blog)

2. Symmetric UDP signaling for SIP & media stack.

Let's concentrate on the 2nd part here as # 1 is covered by Prathap's blog. RTC 1.5 defines 2 new initialization flags to enable symmetric UDP signaling:

RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING

RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP

code e.g.

hr = piRTC2->InitializeEx(RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING |
RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP);

RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING - This enables symmetric UDP signaling. This means that if a profile is used, whose protocol is UDP, then RTC will send & receive SIP packets using a single source port.

RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP - This flag tells RTC to use port 5060 for symmetric UDP signaling. This is not guaranteed as another app may have opened 5060 already, and thus not available for RTC to use it.

Let's see how this tackles the NAT's following 2 major problems:

1. VOIP Devices behind NAT have an internal IP address that is different from outside the NAT and thus outside servers do not know the "real" address of the device.

2. NAT boxes often keep a mapping, of "opened" ports which are time based, and these mappings get closed by the NAT boxes, if there is no live traffic on that port for a particular time.

The above issues are particularly important for UDP protocol as UDP protocol is not connection oriented and hence the 2 devices "may" not use the same ports to send & receive packets.

Let's see how symmetric UDP signaling may solve the above 2 issues.

The most restrictive type of NAT is symmetric NAT, which uses all 4 parts of the tuple <source IP, source port, dest IP, dest port> to restrict traffic follow across them. Using symmetric signaling with Session border controllers (described below), VOIP devices can communicate outside NAT.

These days, most of the VOIP service providers like Vonage, and others are using UDP as their underlying protocol for SIP as well media.

Such service providers often have deployed, what is called the Session Border Controllers. These smart servers often detect clients that are behind the NAT, when the IP addresses in various SIP headers do not match the source IP address of the packets received from such devices behind the NATs. These servers thus ignore the IP address in the SIP headers coming from a device behind the NAT, and reply back on the source IP address/port that is visible on the IP address header. They also reply back using the same IP address/port on which they received the packet. Thus symmetric UDP is achieved. Such a packet from SBC will pass through the NAT and reach the device. If the device behind the NAT is listening on its source IP address/port, that it used to send its outgoing SIP packets to the SBC server, then it can receive packets back from the server.

Thus # 1 problem is solved for SIP for RTC, if symmetric UDP is used with SBC.

In order to keep the mapping alive, the device behind NAT should keep sending packets at regular intervals to keep the port mapping open. These mappings vary across NAT boxes but are in the order of a minute or more. This mapping can be refreshed for SIP, by refreshing REGISTER requests regularly.

RTC now allows a minimum refresh interval of 19 sec. Thus if the SIP server sets its expiry time to less than a minute, RTC will obey that and refresh that frequently.

This solves refreshing port mapping life problem.

The above theory is applicable for media as well. SBC control VOIP media, such that all media for a call goes through them. Consider this:

When a call is made by a device behind the NAT, it inserts the IP address/port of the RTP port in the SDP. When SBC receives this INVITE, it replaces the IP address/port in SDP by its own IP address/port. and then forwards the INVITE to the receiver. When a reply comes back from the receiver, it again replaces the IP address/port in the receiver's SDP, by its own IP address/port. Hence all media now goes through SBC.

The advantage of symmetric UDP now comes in. Now, since all media will go through SBC, and as SBC can communicate with the device using symmetric UDP, the NAT issues for media traffic is also solved.

RTC, by default, supports symmetric UDP for its media traffic. Besides this, it has one more feature called "early UDP" to punch holes early in the call phase, to allow receiving of the traffic from the SBC (for early media scenarios)

SDP are often exchanged in provisional packets like 183 and PRACKs for "early media" scenarios" .Here the device can start getting media from the other side, before the call gets connected (before a final 200 OK response is received for the INVITE). For this scenario, RTC does not start sending any traffic until the 200 is received. But it opens up its receive ports to start receiving the early media.

However, if RTC VOIP device is behind NAT, until a mapping is established on the NAT, NAT won't allow traffic from outside to reach the device inside NAT. Hence RTC's media stack sends "Early UDP" packets to the remote IP address/port, in order to punch holes though the NAT. Once that is done, RTC device can start receiving early media. The early UDP behavior is registry configurable (HKLM\Comm\RTC\NAT, DWORD - EnableEarlyUDPPackets) and is off by default.

[Author: Rajesh Khetan]

What’s new in Real time Communication (RTC) 1.5?

cenet — Wed, 08 Nov 2006 21:08:00 GMT

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.