If you install the recent CE 5.0 QFE's AND try to build Kerberos.dll, you will run into a bug that unfortunately was introduced in this QFE.  Check out customer thread alerting us to it here.

Short summary is that customer is seeing:

"Warning: Unable to do imports from kerberos.dll to NETAPI32.dll - will late bind"

Root cause:

To fix a problem with how Kerberos resolves domain names (basically turning REDMOND domain into a DC controller mydomain-controllername.redmond.microsoft.com), Kerberos was changed to call into the official NetApi32 DsGetDcName instead of using a private interface.  This meant that kerberos has a dependency on Netapi32.dll being in the image which previously it did not.  Customers never think about dependency logic (or hardly ever) because Microsoft runs a large suite of tests to make sure that if component A relies on component B being in the image it explicitly sets it (Kerberos needing Netapi32 in this case) and we fix these issues before releasing the product.

In this case, because it was a QFE we don't usually add dependencies like this, so we didn't catch the dependency prior to QFE release.

The customer workaround is straightforward.  Basically set SYSGEN_NETAPI32=1 (I'm not sure what exactly this translates to in the IDE catalog, probably something like "Domain Discovery").  You only need to do this if you include Kerberos component, which most devices do not.  As near as I can tell, the only way you get kerberos is of course if you manually include it, or if you bring in the voipPhone local authentication plugin (SYSGEN_VOIPPHONE_LAP).

We apologize for the inconvenience.  We're going to be releasing the same QFE effectively in CE6.0 and we will fixup the dependencies prior to releasing that QFE.

John

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.

If you try to build svsutil.hxx on certain versions of the Windows Mobile SDK, you may run into build errors.  I know it's on WM5 SDK at a minimum, I don't know about WM6 SDK. 

The error you'll see will complain about the methods int operator==(int iBit) and int operator==(SVSBitField &bf) in the class SVSBitField in particular.  What happened is that the compiler got a bit more picky at some point but the SDK headers weren't updated to reflect this in the given SDK version.  We have fixed this in latest & greatest svsutil.hxx.

If you run into this, what you'll need to do is change the initial
  for (int i = 0 ; i < m_iWLength - 1 ; ++i) {

So that the 'int i' is outside the for loop, namely:

  int i;
  for (i = 0 ; i < m_iWLength - 1 ; ++i) {

Our apologies to anyone who hits this.

John

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 .

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#>

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

e.g.

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#>

*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.