Java Reference
In-Depth Information
String -based parameterized operations. The native API takes a different
design approach; it is based on a class hierarchy in which there is a
class-based abstraction for every SIP method or header.
SipConnection , the base interface for SIP connections, defines the
String -based addHeader() and setHeader() methods to manage
SIP message headers; SipClientConnection defines the String -
based initRequest() method to initialize the SIP request. In the
native SIP API, the application typically needs to instantiate a CSIPMes-
sageElements object when it is going to send a SIP request. The
headers that are put into the CSIPMessageElements object are not
String s but are encapsulated in subclasses of the CSIPHeaderBase
class (e.g., CSIPContactHeader ). Another class, CSIPRequestEle-
ments , contains the CSIPMessageElements and the mandatory parts
of any SIP request such as the To header, From header, Remote URI, and
request method.
In the native SIP API, each supported SIP method is encapsulated by a
subclass of the CSIPDialogAssocBase class (e.g., CSIPInviteDi-
alogAssocBase ).
These different design approaches enforce different API usage. For
example, using JSR-180 SIP, the application creates a SipClientCon-
nection using the GCF factory method, invokes initRequest() with
an INVITE String , and adds or sets the headers using addHeader()
or setHeader() . The following snippet of code demonstrates sending
scc = (SipClientConnection);
// initialize INVITE request
scc.initRequest("INVITE", null);
scc.setHeader("From", "");
scc.setHeader("Accept-Contact", "*;type="app/chess"");
scc.setHeader("Contact", "sip:user@" + localAddress);
scc.setHeader("Content-Length", "" + sdp.length());
scc.setHeader("Content-Type", "application/sdp");
Using the native API, the application creates the CSIPInviteDi-
alogAssoc and CSIPMessageElements objects. The application fills
the relevant SIP headers into CSIPMessageElements before passing it
to CSIPInviteDialogAssoc using the SendInviteL() function.
In short, the two APIs are fundamentally different. The solution to those
different design approaches was to have native peers for Java objects,
which would include an internal layer whose functionality is to translate
between String s and classes.
Since there is no exact equivalent in native code to the Java classes,
a peer object is actually a container of native SIP classes executing upon
them according to changing states, triggered by Java method invocations.
Search WWH ::

Custom Search