From Forum Nokia Wiki

ID	TSS000374	Creation date	July 7, 2006
Platform	S60 3rd Edition	Devices
Category	Symbian C++	Subcategory

Keywords (APIs, classes, methods, functions):

Overview

Method User::WaitForRequest() is used with the ETel 3rd Party API (CTelephony)

Description

The ETel 3rd Party API (that is, CTelephony) was designed to be used in asynchronous mode, with its methods called from an active object that is then going to wait for the method to complete. As an active object can have, by definition, only one active request at a time, the asynchronous methods of Telephony are designed to panic (with "Telephony 0") whenever it is detected during a method call that the TRequestStatus parameter passed to this method (in fact, the iStatus member of CActive) is already set to KRequestPending.
A common (although not recommended) practice among Symbian developers is to "synchronize" the asynchronous method calls with the User::WaitForRequest to block the thread until the operation completes.
There are two major problems with this approach:
- The asynchronous call can take a long time until it completes and keeping the thread blocked for the entire time can cause a VIEWSERV 11 panic (see Symbian’s FAQ-0920).
 - The asynchronous method may be implemented using other active objects and asynchronous methods running on the same thread. If so, the methods can never complete since the thread is blocked and as such, the thread will remain blocked forever.
In a concrete case of CTelephony and considering the following code example:
CTelephony::TBatteryInfoV1 batterystrength;
CTelephony::TBatteryInfoV1Pckg battery(batterystrength);
CTelephony* tel = CTelephony::NewLC();
TRequestStatus status = KRequestPending; // (1)
tel->GetBatteryInfo(status, battery);
User::WaitForRequest(myStat); // (2)
...
CleanupStack::PopAndDestroy();
This means:
- The TRequestStatus variable is initialized with KRequestPending - line  (1)  - a very common mistake that usually does not affect the API calls except that with CTelephony it will cause the "Telephony 0" panic as described above. Please note that a TRequestStatus variable should, in general, not be initialized.
- Assuming that the initialization from (1) is removed, the code will never return from line (2) as CTelephony’s asynchronous methods cannot complete while the thread is blocked.
In conclusion, CTelephony must always be used asynchronously, from within an active object. Moreover, User::WaitForRequest must be used with caution.