Bodies

From reSIProcate
Jump to: navigation, search

Message Bodies[edit]

Bodies are carried in SIP messages and are accessed with getContents and setContents. The bodies are stored as pointers to the Contents base type. Typically, use dynamic_cast to the desired type to access the derived body type.

Contents has a static map from mime type to Content factory. This map needs to be populated at startup. To do this the unit that contains your main needs to #include the header files for each Contents* subclass that you will use anywhere in your application. This is very important. If you do not include these header files in your main, the contents map will not know to create the mapping and in fact the dynamic linker will not load the code. This also provides a method to leave out Contents that your application does not use.

#include "resiprocate/SdpContents.hxx"
#include "resiprocate/Pidf.hxx"

int main(int argc, char** argv)
{
   // application here
}

Type Mapping[edit]

The type of the body is determined when parsing an incoming message. The body's type is determined by the MIME type in the messages Content-Type header.

The MIME type maps to a unique derived concrete Content type that parses and provides access to the parts of the body. This mapping can be modified by altering the derived Contents types that are #included in your application. For example, the class SdpContents causes itself to be the contents handler for the MIME type application/sdp. When included, SdpContents will be invoked as the parser and interface for SDP bodies.

A different class can be specified to parse SDP by defining it to return application/sdp from its getStaticType() and including this class instead of SdpContents. Including two content handling classes for the same MIME type will causes an immediate run-time error.

Accessing[edit]

The SDP body of a parsed message can be accessed with:

SdpContents* sdp = dynamic_cast<SdpContents*>(msg->getContents());

SdpContents provides a rich interface to the components of the SDP body.

Setting[edit]

Similarly, an SdpContents can be constructed and populated at run time and then made to be the body of an outgoing message. The Content-Type of the containing message will be set appropriately and the message will be serialized to the wire with the SDP body:

SdpContents sdp;
...
msg->setContents(&sdp); // copy the sdp into the message

Alternatively, the copy can be avoided:

SdpContents* sdp;
...
std::auto_ptr<Contents*> contents(sdp);
msg->setContents(contents) // transfer the sdp to the message

Content Headers[edit]

Content headers are set on the content instance. The headers are output as part of the container's headers when the contents is placed in the container. For example, a SipMessage containing a MIME content will output these headers as SipMessage headers. When parsed, the content specific header information is migrated into the contained contents. Contents containers include SipMessage and multipart derived Contents.

Content headers are accessed analogously to SIP message headers. Each header has an accessor token used to overload the header method. The following headers are used in Contents and in SipMessage.

RFC NamereSIP Access TokenreSIP Type
Content-Dispositionh_ContentDispositionToken
Content-Encodingh_ContentEncodingToken
Content-Languageh_ContentLanguagesTokens
Content-Transfer-Encodingh_ContentTransferEncodingStringCategory

The following headers are MIME specific. These headers are accessible on Contents only. These headers appear in encoded bodies only when the content is MIME wrapped (for example, contained in a MultipartRelatedContents).

RFC NamereSIP Access TokenreSIP Type
Content-IDh_ContentIDToken
Content-Descriptionh_ContentDescriptionStringCategory

Notably absent from the set of accessible headers is Content-Length. The length of the content is caclulated from the concrete contents and is not settable.

For each header type, there is a header access method, exists method, and a remove method.

Class Hierarchy[edit]

Class Hierarchy