×
Namespaces

Variants
Actions

Indicating SIP User Agent Capabilities

From Nokia Developer Wiki
Jump to: navigation, search
Article Metadata
Platform Security
Capabilities: ProtServ
Article
Created: judith14 (27 Jul 2007)
Last edited: hamishwillee (24 Jan 2012)

SIP user agents vary widely in their capabilities and in the types of devices they represent.It is important for another SIP element to learn the capabilities and characteristics of a SIP user agent.

SIP User Agent capability is an attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content.Capability and characteristic information about a UA is carried as parameters of the Contact header field. These parameters can be used within REGISTER requests and responses, OPTIONS responses, and requests and responses that create dialogs (such as INVITE). The Allow,Accept, Accept-Language, and Supported header fields convey some information about the capabilities of a SIP user agent.

In S60 SIP clients interested in receiving SIP requests must provide an XML description with their capabilities, i.e. the supported content types and media formats, using SIP headers and SDP m-lines in the ECom resource file. Target clients must implement an ECom interface called Client Resolver API, meaning that every target client must provide an ECom plug-in to be used within Client Resolver Framework.

SIP Client Resolver determines the target client based on the provided SIP request and on the XML description provided by every SIP Client Resolver API implementation. SIP Client Resolver requests the resolved ECom plug-in to connect to the Symbian OS server that is SIP or uses SIP.

The capability needed to use Client Resolver API is ProtServ.

All the applications using Client Resolver must announce their capabilities by implementing an ECom-plug-in. These plug-ins are monitored and used by the Client Resolver. The application capabilities are described in the ECom-plug-in’s resource file using XML.

An example of a capabilities definition in XML format is provided below.

<SIP_CLIENT ALLOW_STARTING="YES">
<SIP_HEADERS>
<ACCEPT_CONTACT value="*;mobility="mobile";media="audio"" />
<ALLOW_EVENTS value="presence" />
<ACCEPT value="somecontent/type" />
<ACCEPT value="application/sdp" />
<ACCEPT value="application/pidf+xml"/>
<ACCEPT value="text/plain"/>
</SIP_HEADERS>
<SDP_LINES>
<LINE name="m" value="audio 30000 RTP/AVP 98" />
</SDP_LINES>
</SIP_CLIENT>

Source code

CSipAppLauncher.H

// INCLUDES
#include <apgcli.h>
#include <SipResolvedClient.h>
 
 
// CLASS DEFINITION
 
/**
* CSIPIMResolverPlugin implements a simple plugin for testing ClientResolver.
*/

class CSIPIMResolverPlugin : public CSIPResolvedClient
{
public: // Constructors and destructor
 
static CSIPIMResolverPlugin* NewL();
 
/// Destructor
~CSIPIMResolverPlugin();
 
public: // from CSIPResolvedClient
 
TUid ChannelL( RStringF aMethod,
const TDesC8& aRequestUri,
const RPointerArray<CSIPHeaderBase>& aHeaders,
const TDesC8& aContent,
const CSIPContentTypeHeader* aContentType=0);
 
void ConnectL( TUid aUid );
 
const TDesC8& Capabilities();
 
private: // Constructors
 
inline CSIPIMResolverPlugin() {}
 
// Second phase constructor
void ConstructL();
 
private: // New functions
 
 
// Name
RApaLsSession iApaSession;
TApaAppInfo iAppInfo;
 
TUid iApplicationUID;
};
 
#endif // __SIPIMRESOLVER_H__


CSipAppLauncher.CPP

//  Include Files  
#include "CSipAppLauncher.h"
#include <apacmdln.h>
 
// SIPIM capabilities - could be also defined in resource of this plugin
// but then length of capablities text is in resource file limited to
// 255 characters. However, defining capabilities in resource file's opaque_data
// field is more efficient way.
_LIT8(KCapabilities,
"<SIP_CLIENT ALLOW_STARTING=\"YES\">\
<SIP_HEADERS>\
<ACCEPT value=\"application/pidf+xml\"/>\
<ACCEPT value=\"text/plain\"/>\
</SIP_HEADERS>\
</SIP_CLIENT>"
);
 
 
CSIPIMResolverPlugin* CSIPIMResolverPlugin::NewL()
{
CSIPIMResolverPlugin* self = new ( ELeave ) CSIPIMResolverPlugin;
CleanupStack::PushL( self );
self->ConstructL();
CleanupStack::Pop( self );
return self;
}
 
 
void CSIPIMResolverPlugin::ConstructL()
{
const TUid KMyImplementationUid = { KSIPResolverPluginUID };
 
RImplInfoPtrArray infoArray;
REComSession::ListImplementationsL( KSIPResolvedClientIFUid, infoArray );
CleanupStack::PushL( TCleanupItem( ResetAndDestroy, &infoArray ) );
 
TBool found = EFalse;
for ( TInt i=0; !found && i < infoArray.Count(); i++ )
{
CImplementationInformation* info = infoArray[ i ];
if ( info->ImplementationUid() == KMyImplementationUid )
{
TLex8 lex( info->DataType() );
TUint value( 0 );
User::LeaveIfError( lex.Val( value, EHex ) );
iApplicationUID.iUid = value;
found = ETrue;
}
}
 
CleanupStack::PopAndDestroy( 1 ); // infoArray
 
if ( !found )
{
User::Leave( KErrNotFound );
}
 
User::LeaveIfError( iApaSession.Connect() );
User::LeaveIfError( iApaSession.GetAppInfo( iAppInfo, iApplicationUID ) );
}
 
 
CSIPIMResolverPlugin::~CSIPIMResolverPlugin()
{
iApaSession.Close();
}
 
 
TUid CSIPIMResolverPlugin::ChannelL( RStringF /*aMethod*/,
const TDesC8& /*aRequestUri*/,
const RPointerArray<CSIPHeaderBase>& /*aHeaders*/,
const TDesC8& /*aContent*/,
const CSIPContentTypeHeader* /*aContentType*/)
{
return iApplicationUID;
}
 
 
 
void CSIPIMResolverPlugin::ConnectL( TUid aUid )
{
// Launch app based on uid passed from SIP stack
//
TApaAppInfo appInfo;
User::LeaveIfError( iApaSession.GetAppInfo( appInfo, aUid ) );
CApaCommandLine* cmdLine = CApaCommandLine::NewLC();
#ifdef EKA2
cmdLine->SetExecutableNameL( appInfo.iFullName );
#else
cmdLine->SetLibraryNameL( appInfo.iFullName );
#endif
User::LeaveIfError( iApaSession.StartApp( *cmdLine ) );
CleanupStack::PopAndDestroy( cmdLine );
}
 
const TDesC8& CSIPIMResolverPlugin::Capabilities()
{
return KCapabilities;
}
This page was last modified on 24 January 2012, at 05:31.
26 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×