Calls are represented by pj::Call class.

Subclassing the Call class

To use the Call class, application SHOULD subclass it, such as:

class MyCall : public Call
    MyCall(Account &acc, int call_id = PJSUA_INVALID_ID)
    : Call(acc, call_id)
    { }

    { }

    // Notification when call's state has changed.
    virtual void onCallState(OnCallStateParam &prm);

    // Notification when call's media state has changed.
    virtual void onCallMediaState(OnCallMediaStateParam &prm);

Application implement Call’s callbacks to process events related to the call, such as pj::Call::onCallState(), and many more. See pj::Call class for more info.

Making outgoing calls

Make outgoing call is by invoking pj::Call::makeCall() with the destination URI string (something like ""). The URI can also be enclosed in name-addr form ([ display-name ] <SIP/SIPS URI>) (such as "Alice <;transport=tcp>"). Note that an account instance is required to create a call instance:

Call *call = new MyCall(*acc);
CallOpParam prm(true); // Use default call settings
try {
    call->makeCall(dest_uri, prm);
} catch(Error& err) {
    cout << << endl;

Receiving Incoming Calls

Incoming calls are reported as pj::Account::onIncomingCall() callback. Note that this is the callback of the pj::Account class (not pj::Call). You must derive a class from the pj::Account class to handle incoming calls.

Below is a sample code of the callback implementation:

void MyAccount::onIncomingCall(OnIncomingCallParam &iprm)
    Call *call = new MyCall(*this, iprm.callId);
    CallOpParam prm;
    prm.statusCode = PJSIP_SC_OK;

For incoming calls, the call instance is created in the callback function as shown above. Application should make sure to store the call instance during the lifetime of the call (that is until the call is disconnected (see Call Disconnection below)).

Call Properties

All call properties such as state, media state, remote peer information, etc. are stored in pj::CallInfo class, which can be retrieved from the call object with using pj::Call::getInfo() method.

Call Disconnection

Call disconnection event is a special event since once the callback that reports this event returns, the call is no longer valid and any operations invoked to the call object will raise error exception. Thus, it is recommended to delete the call object inside the callback.

The call disconnection is reported in pj::Call::onCallState() callback. Below is a sample implementation:

void MyCall::onCallState(OnCallStateParam &prm)
    CallInfo ci = getInfo();
    if (ci.state == PJSIP_INV_STATE_DISCONNECTED) {
        /* Delete the call */
        delete this;

Working with Call’s Audio Media

Application can only operate the call’s audio media when the call’s audio media state is ready (or active). Usually this happens once the call has been established, although media can active before that (it is called early media), and established call can have no media (such as when it is being put on-hold).

The changes to the call’s media state is reported in pj::Call::onCallMediaState() callback. Only when the call’s audio media state is ready (or active) the function pj::Call::getMedia() will return a valid audio media.

Below is a sample code to connect the call to the sound device when the media is active:

void MyCall::onCallMediaState(OnCallMediaStateParam &prm)
    CallInfo ci = getInfo();

    for (unsigned i = 0; i <; i++) {
        if ([i].type==PJMEDIA_TYPE_AUDIO && getMedia(i)) {
            AudioMedia *aud_med = (AudioMedia *)getMedia(i);

            // Connect the call audio media to sound device
            AudDevManager& mgr = Endpoint::instance().audDevManager();

When the audio media becomes inactive (for example when the call is put on hold), there is no need to stop the call’s audio media transmission since they will be removed automatically from the conference bridge, and this will automatically remove all connections to/from the call.

Call Operations

Call have many other operations, such as hanging up, putting the call on hold, sending re-INVITE, etc. See pj::Call reference for more info.

Instant Messaging(IM)


Usually it is more appropriate to do instant messaging outside the context of a call. Application can send IM and typing indication outside a call by using pj::Buddy::sendInstantMessage() and pj::Buddy::sendTypingIndication(). More will be explained in the next section.

Application can send IM within a call using pj::Call::sendInstantMessage(). The transmission status of outgoing instant messages is reported in pj::Call::onInstantMessageStatus() callback.

In addition, you can also send typing indication using pj::Call::sendTypingIndication().

Incoming IM and typing indication received within a call will be reported in pj::Call::onInstantMessage() and pj::Call::onTypingIndication() callbacks.

While it is recommended to send IM outside call context, application should handle incoming IM inside call context for robustness.