SIP SIMPLE Client SDK

= Developer guide =

<abbr title="WikiStart, Sip*, depth=2">TOC</abbr>

The main goal of this library is to provide a simple to use API to create real-time communications applications between end-points based on SIP protocol.

Middleware API

To develop your applications you should use the middleware API. The middleware API hides the complexity and interactions of the lower level SIP, RTP, MSRP and XCAP protocols.

• [wiki:SipMiddlewareApiDocumentation Middleware API]
• [wiki:SipSettings Configuration API] - configuration framework that will replace the current configuration file config.ini, all middleware components will have access to all settings throught it

Components APIs

You can use the following APIs that provides granular control of their respective components to develop your own high level API or application:

• [wiki:SipCoreApiDocumentation SIP core API] - The API for the SIP, RTP, ICE and audio engine
• [wiki:SipMSRPApiDocumentation MSRP API] - The API for Message Session Relay Protocol used for instant messaging, file transfer and desktop sharing
• [wiki:SipPresenceApiDocumentation Presence API] - The API for payload types used for publication, subscription and notifications of SIP events
• [wiki:SipXCAPApiDocumentation XCAP API] - The API for XCAP document manipulation used for storage of buddy lists and presence policy documents

Contributing

If you want to help us fixing a bug that you found or if you want to contribute with a new feature you must be familiar with the darcs version control system from http://darcs.net.

First make sure you are using the latest version by doing a 'darcs pull'.

Then record your changes using 'darcs record'. Follow the following guidelines for recording your changes:

• Keep a patch name under 74 characters, so that a darcs changes in a 80 char console is consistent and readable. If you need to write more than that, use --edit-long-comment or do not specify -m "patch name" and it will automatically ask for a patch name and a long comment. Also keep the long comment inside the 80 char frame
• When you add a long comment, you have the patch name on the first line. After that, leave an empty line and then add the long comment starting from the 1st column. If you need to add bulleted entries in the long comment, use a dash (-) not an asterisk (*), to avoid confusion with the asterisk darcs places before every patch name.
• Record separate patches for each distinct changes you make. Do not mix different changes in a single record.
• Use darcs replace to rename tokens if possible instead of using a search and replace in your editor. It correctly handles cases where someone else still kept using the old name (it will automatically rename this uses of the old name when he pull the darcs replace patch, which a simple token rename done by the editor and recorded as a standard diff will never do, requiring further patches to rename the old tokens that the other developer added in his code while you were doing the renaming).

Finally open a ticket at http://sipsimpleclient.com/newticket describing your patch and the problem solved and submit the patch using:

{{{
darcs send --to devel@ag-projects.com
}}}

• [wiki:SipContributions Third-party contributions] page.