I've recorded this change as "closed approved automatic," as the
changes appear to quite straightforward and need no substantial
discussion. If you disagree, please speak up quickly. (Submitter:
please wait at least 24 hours before putting back.)
The release binding is "patch/micro" and consolidation is "ON." The
stability level for the two interfaces introduced is "Committed."
Following are the two interfaces:
(1) sip_get_dialog_local_contact_uri
(2) sip_create_dialog_req_nocontact
(The naming convention is in keeping with existing SIP API)
Addition of sip_get_dialog_local_contact API:
=============================================
A SIP dialog is created when a session is established between two
User Agents. The characteristics of a dialog is represented by an
internal C structure (sip_dialog) at each User Agent. This
structure is private and the definition is not exposed to
applications.
Access to the member elements of the structure by User Application
is through accessors like sip_get_dialog_state,
sip_get_dialog_local_cseq, et al. CR 6583537 introduced new element
(local_contact header) to the structure. In order to make this
information available to applications we need a new public method
called sip_get_dialog_local_contact_uri.
Details: (API declaration)
--------------------------
const struct sip_uri *sip_get_dialog_local_contact_uri(
sip_dialog_t dialog, int *error);
dialog: Represents the structure from which the local_contact_uri
needs to be retrieved.
error: Determines if the function call was successful. *error = 0
means "success" and *error = EINVAL means "failure."
Addition of sip_create_dialog_req_nocontact API:
================================================
Once a dialog has been established between two User Agents, new
requests within the dialog are generated by the SIP API
sip_create_dialog_req(). This API uses the information stored in
the sip_dialog structure to generate new requests.
However within a session there is a possibility that either of the
User Agent might desire to change its location. User Agent which
desires to do so issues re-INVITE request with new Contact header,
which specifies the new location. In such situations the existing
API sip_create_dialog_req() isn't that helpful. It creates a
request with the contact information maintained in the dialog. Thus
the application has to delete the existing contact header and add a
new one to resulting request [generated by sip_create_dialog_req()].
This case adds an API that does not add the the contact header to
the request and allows application to add the new header.
Details: (API declaration)
--------------------------
sip_msg_t sip_create_dialog_req_nocontact(sip_method_t method,
sip_dialog_t dialog, char *transport, char *sent_by,
int sent_by_port, char *via_param, uint32_t smaxforward,
int cseq)
Function sip_create_dialog_req_nocontact is identical to the
existing API sip_create_dialog_req() except that the returned
sip_msg_t will not have a "contact" header.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
