Category: SIP

From Forum Nokia Wiki

SIP Extension Methods supported by S60 SIP Stack

PUBLISH --- Publishing of presence information

SUBSCRIBE/NOTIFY --- SIP Events

MESSAGE --- SIP Extensions for Instant Messaging

PRACK --- Reliability of Provisional Responses in SIP

UPDATE --- Early media and preconditions, The SIP UPDATE Method

INFO --- Mid call signaling information, The SIP INFO Method

REFER --- SIP REFER Method

PUBLISH Method

PUBLISH Method is used for publishing event state information like Presence event and Reg events.

A typical flow of messages would be

         PUA                     PA                      WATCHER
                           
          |                       |                      |
          |                       | <----- SUBSCRIBE --- |
          |                       |                      |
          |                       | ------ 200 OK -----> |
          |                       |                      |
          |                       | -----  NOTIFY -----> |
          |                       |                      |
          |                       | <----  200 OK ------ |
          |                       |                      |
          |                       |                      |
          | -------  PUBLISH ---> |                      |
          |                       |                      |
          | <------  200 OK ----  |                      |
          |                       |                      |
          |                       | -----  NOTIFY -----> |
          |                       |                      |
          |                       | <----  200 OK ------ |
          |                       |                      |
          | -------  PUBLISH ---> |                      |
          |                       |                      |
          | <------   200 OK ---  |                      |
          |                       |                      |
          |                       |                      |
          | -------  PUBLISH ---> |                      |
          |                       |                      |
          | <------  200 OK ----  |                      |
          |                       |                      |
          |                       | ------  NOTIFY ----> |
          |                       |                      |
          |                       | <-----  200 OK ----- |
          |                       |                      |

PUA is Presence User Agent. PA is Presence Agent.

Sending a SIP PUBLISH request

In order to send a SIP request, the application creates an instance of CSIPRequestElements, and sets the desired parts of the request. Once CSIPRequestElements has been filled, the application invokes the CSIPConnection::SendRequestL(CSIPRequestElements*) function. CSIPConnection takes the ownership of CSIPRequestElements and communicates the request to the server side of the SIP stack. CSIPConnection instantiates CSIPClientTransaction and returns it to the application. SendRequestL initiates the server side processing of sending the PUBLISH Method, but the time consuming tasks such as address resolving and socket operations are done only after the SendRequestL call has returned. If an error occurred after SendRequestL has returned, the error is communicated to the application by MSIPConnectionObserver::ErrorOccured . It is important to understand that when SendRequestL returns, the PUBLISH has not yet been sent to the network but is being processed on the server side of the SIP stack.

Once SendRequestL has returned and the sending of a PUBLISH continues on the shared server, there is no way for the application to cancel the operation. This applies to other kinds of operations, too. Note that the CSIPClientTransaction::CancelL function is used to send a SIP CANCEL request after the application has first sent an INVITE request.

When the SIP response message is received from the server side, CSIPConnection forms a CSIPResponseElements object to represent the SIP response, attaches it to CSIPClientTransaction and notifies the application with MSIPConnectionObserver:: IncomingResponse. The application can determine what kind of a response was received by accessing CSIPResponseElements from CSIPClientTransaction. As the response was a provisional response, the application does not delete CSIPClientTransaction yet . Later, a 200 response is received and the application deletes CSIPClientTransaction , which has now completed.

Following code snippet is for publishing "presence" event.

void CSIPExEngine::Publish()
{
 
//get aor from the profile
 
const CDesC8Array& aor= (CDesC8Array&) iProfile->AORs();
TPtrC8 a=aor[0];
 
 
CSIPAddress* toAddress =CSIPAddress::DecodeL(a);
CleanupStack::PushL(toAddress);
 
CSIPToHeader* toHeader = CSIPToHeader::NewL(toAddress);
CleanupStack::Pop(toAddress);
CleanupStack::PushL(toHeader);
 
CSIPRequestElements* reqElems = CSIPRequestElements::NewL(toHeader); 
CSIPMessageElements& MessageElements1=reqElems->MessageElements();
 
TBuf8<512> doc;
 
_LIT8(kdoc1,"<?xml version=\"1.0\" encoding=\"UTF-8\"?>
      <presence xmlns=\"urn:ietfarams:xml:nsidf\" entity=\"");
_LIT8(kdoc2,"\"><tuple id=\"tup1\" ><status><basic>open</basic></status><note>"); 
_LIT8(kdoc3,"</note></tuple></presence>"); //presence document
 
doc.Copy(kdoc1);
doc.Append(a);
doc.Append(kdoc2);
doc.Append(_L8("Online");
doc.Append(kdoc3);
 
MessageElements1.SetContentL(doc.AllocL(),
    CSIPContentTypeHeader::NewL(_L8("application"),_L8("pidf+xml")));
 
RPointerArray <CSIPHeaderBase> myheader1(1);
 
CSIPEventHeader* EventHeader1=CSIPEventHeader::NewL ( _L8("presence")); 
myheader1.Append(EventHeader1);
 
MessageElements1.SetUserHeadersL(myheader1);
 
CleanupStack::Pop(); //toHeader
 
CleanupStack::PushL(reqElems);
reqElems->SetMethodL(SIPStrings::StringF( SipStrConsts::EPublish ));
 
 
// Get the current connection
	TUint32 iapId( 0 );
	User::LeaveIfError( iProfile->GetParameter( KSIPAccessPointId, iapId ) );
	CSIPConnection* conn = CSIPConnection::NewL( *iSIP, iapId, *this );
	
		
        CSIPClientTransaction* clientTx = conn.SendRequestL( reqElems );
	CleanupStack::Pop( reqElems );
 
	delete clientTx;
 
 
}

SUBSCRIBE/NOTIFY Method

The general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network,and those entities (or entities acting on their behalf) can send notifications when those states change.

A typical flow of messages would be

    Subscriber          Notifier
      |-----SUBSCRIBE---->|     Request state subscription
      |<-------200--------|     Acknowledge subscription
      |<------NOTIFY----- |     Return current state information
      |--------200------->|
      |<------NOTIFY----- |     Return current state information
      |--------200------->|

Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages. sending Subscribe is almost like Publish method described above only.Using CSIPSubscribeDialogAssoc class also we can send SUBSCRiBE method.

UPDATE method

UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but can be sent before the initial INVITE has completed. This makes it very useful for updating session parameters within early dialogs.

REFER Method

The REFER method indicates that the recipient (identified by the SIP Request-URI) should contact a third party using the contact information provided in the request. A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog.