conformance.docs

Sofia SIP is an open-source SIP User-Agent library, compliant with the IETF RFC3261 specification.

<a name="3323"></a>
<tr valign=top>
    <th align="left">
	@RFC3323: Privacy
    </th>
    <td>
	@ref sip_privacy "Privacy" header is supported (generating, parsing
        and syntax checking).

	Call-Id header is generated from cryptographically random id without
	host name or IP address. By default, @ref sip_contact "Contact" and
	@ref sip_via "Via" headers contain only IP address that can be
	dynamically allocated.

	Application can enter any SIP URI and display name to From header,
	e.g., @code Anonymous <sip:[e-mail]> @endcode.
    </td>
    <td>
        Application must take care of:
	- Properly populating the URIs and display names within SIP headers
	- Not including any optional headers that could reveal identity
	- Generating of Privacy header with appropriate values
	- Generating of Proxy-Require: privacy
	- Using anonymous callback URIs etc.
    </td>
</tr>


<a name="3326"></a>
<tr valign=top>
    <th align="left">
	@RFC3326: Reason
    </th>
    <td>
	Sofia-SIP supports @ref sip_reason "Reason" header (generating,
	parsing and syntax checking).
    </td>
    <td>
        Application must take care of:
	- Generating or processing Reason headers
    </td>
</tr>


<a name="3325"></a>
<tr valign=top>
    <th align="left">
	@RFC3325: Asserted Identity
    </th>
    <td>
	Sofia-SIP supports 
	@ref sip_p_asserted_identity "P-Asserted-Identity" and
	@ref sip_p_preferred_identity "P-Preferred-Identity" headers
        (generating, parsing and syntax checking). Also the non-standard
        header @ref sip_remote_party_id "Remote-Party-ID" is supported.

        @NEW_1_12_7.
    </td>
    <td>
	Not implemented:
        - <a href="#3323">id privacy</a>
	- Recognizing trust domains and enforcing handling of headers
	  based on those
    </td>
</tr>

<a name="3327"></a>
<tr valign=top>
    <th align="left">
	@RFC3327: Path
    </th>
    <td>
	User-agent engine can add "path" option tag to Supported header of
	REGISTER requests.

	Sofia-SIP explicitly supports @ref sip_path "Path" header
	(generating, parsing and syntax checking).
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<a name="3329"></a>
<tr valign=top>
    <th align="left">
	@RFC3329:
	Security Agreement
    </th>
    <td>
	Some support of the SIP Security Mechanism Agreement procedures. The
	client is able to insert Security-Client and Security-Verify header
	with fake @e d-ver value.

	Sofia-SIP explicitly supports (generating, parsing
	and syntax checking)
	@ref sip_security_client "Security-Client",
	@ref sip_security_server "Security-Server", and
	@ref sip_security_verify "Security-Verify" headers.

	Security-mechanism supported is "digest".
    </td>
    <td>
	Correct @e d-ver value is not calculated.
    </td>
</tr>

<a name="3361"></a>
<tr valign=top>
    <th align="left">
	@RFC3361: DHCPv4 option for locating SIP servers.
    </th>
    <td>
	Sofia-SIP supports outbound proxy.
    </td>
    <td>
	Application must take care of:
	- passing outbound proxy name or address from DHCP client
          to Sofia-SIP stack.
    </td>
</tr>

<a name="3420"></a>
<tr valign=top>
    <th align="left">
	@RFC3420: message/sipfrag
    </th>
    <td>
	Sofia-SIP passes the received SIP message headers to application
	which can create a message/sipfrag payload.
    </td>
    <td>
        Application must take care of:
	- processing the SIP message fragments
    </td>
</tr>

<a name="3428"></a>
<tr valign=top>
    <th align="left">
	@RFC3428: MESSAGE
    </th>
    <td>
	MESSAGE method is supported natively.
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<a name="3486"></a>
<tr valign=top>
    <th align="left">
	@RFC3486: Compressing SIP
    </th>
    <td>
	Sofia-SIP provides support for using comp=sigcomp parameters in @ref
	sip_via "Via" header and @ref url_t "SIP URIs", indicating
	support for compression.
    </td>
    <td>
	SigComp itself is not supported.
    </td>
</tr>

<a name="3515"></a>
<tr valign=top>
    <th align="left">
	@RFC3515: REFER
    </th>
    <td>
	REFER method is supported natively. Sofia-SIP processes incoming
        REFER requests and generates NOTIFY with correct
	@ref sip_event "Event" header automatically.

	Further notifications can be automatically generated actions when
	nua_invite() is given referrer's nua handle in NUTAG_NOTIFY_REFER().

	Sofia-SIP explicitly supports (generating, parsing and syntax
	checking) @ref sip_refer_to "Refer-To" ("r") SIP header.

	See also support for
	<a href="#3891">RFC 3891</a> and
        <a href="#3892">RFC 3892</a>.
    </td>
    <td>
        &nbsp;
    </td>
</tr>

<a name="3608"></a>
<tr valign=top>
    <th align="left">
	@RFC3608: Service-Route
    </th>
    <td>
	Sofia-SIP supports @ref sip_service_route "Service-Route" that can
	be used to provide a mechanism by which a registrar may inform a
	registering UA of a service route. User-Agent will optionally use
	the route provided in @ref sip_service_route "Service-Route" header.

	The SIP header explicitly supported (generating, parsing and
	syntax checking) is @ref sip_service_route "Service-Route".
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<a name="3680"></a>
<tr valign=top>
    <th align="left">
	@RFC3680: "reg" event
    </th>
    <td>
	Sofia-SIP supports <a href="#3265">generic SIP event support</a> for
	subscribing SIP event packages and receiving notifications for them.
	Subscriptions are refreshed before expiration when needed and
	subscriptions are terminated on request. Sofia-SIP takes care of
        notified subscription states.

	UA can SUBSCRIBE to a registration state event package after sending
	initial REGISTER to, e.g., 3GPP network and use it to follow its
        registration status.
    </td>
    <td>
	Application must take care of:
	- Generating subscriptions for "reg" event
	- Processing notifications for "reg" event
	  - Handling of XML document in notifications
    </td>
</tr>

<a name="3824"></a>
<tr valign=top>
    <th align="left">
	@RFC3824: ENUM
    </th>
    <td>
	Tel URIs are supported in any headers including URI parameters,
	e.g., To, From, Contact headers, and Request-URI of the outgoing SIP
	request provided that the next hop is given as SIP or SIPS URI.
    </td>
    <td>
	Stack can not resolve E.164 number to address of next
	hop. A proxy in the network must resolve E.164 numbers with ENUM.
    </td>
</tr>

<a name="3840"></a>
<tr valign=top>
    <th align="left">
	@RFC3840: Callee Capabilities
    </th>
    <td>
	Feature parameters can be added to SIP profiles and sent within
	Contact header of REGISTER request as header parameters.

	UAC can optionally generate media tags for Contact header using
	local media profile.

	Feature parameters can also be sent within any other SIP request as
	extension parameters of Contact header.
    </td>
    <td>
	Application must take care of:
        - Processing the feature parameters received in the Contact header
    </td>
</tr>


<a name="3841"></a>
<tr valign=top>
    <th align="left">
	@RFC3841: Caller Preferences
    </th>
    <td>
	Built-in support for user-agent behavior.

	UAC can optionally generate Accept-Contact header using local media
	profile.

	SIP parser parses the Accept-Contact and Reject-Contact headers.

        ACK and CANCEL request messages sent have same values
	for Accept-Contact/Reject-Contact or Request-Disposition
	headers as the original request had.

	There are functions for calculating score for contacts.

	The SIP headers explicitly supported (generating,
	parsing and syntax checking) are:
	@ref sip_request_disposition "Request-Disposition" ("d"),
	@ref sip_accept_contact "Accept-Contact" ("a"),
	@ref sip_reject_contact "Reject-Contact" ("j"),
    </td>
    <td>
	Application must take care of:
        - UAS processing incoming Accept-Contact or Reject-Contact headers
    </td>
</tr>

<a name="3842"></a>
<tr valign=top>
    <th align="left">
	@RFC3842: Message waiting event
    </th>
    <td>
	Sofia-SIP supports <a href="#3265">generic SIP event support</a> for
	subscribing SIP event packages and receiving notifications for them.
	Subscriptions are refreshed before expiration when needed and
	subscriptions are terminated on request. Sofia-SIP takes care of
        notified subscription states.
    </td>
    <td>
	Application must take care of:
	- Generating subscriptions for "message-summary" event
          - Including correct @ref sip_event "Event" and
            @ref sip_accept "Accept" headers in the request (if needed)
	- Processing notifications for "message-summary" event
	  - Handling of summary information in notifications
    </td>
</tr>

<a name="3856"></a><a name="3859"></a>
<tr valign=top>
    <th align="left">
	@RFC3856: Presence <br>
	@RFC3859: Common Profile for Presence
    </th>
    <td>
	Sofia-SIP supports <a href="#3265">generic SIP event support</a> for
	subscribing SIP event packages and receiving notifications for them.
	Subscriptions are refreshed before expiration when needed and
	subscriptions are terminated on request. Sofia-SIP takes care of
        notified subscription states.

	Note: Usage of pres: URI is supported only if the next hop URI to
	where to send SUBSCRIBE is a SIP URI (e.g. of outbound proxy).
	Resolving of pres: URIs by DNS is not supported.
    </td>
    <td>
	Application must take care of:
	- Generating subscriptions for "presence" event
          - Including correct @ref sip_event "Event" and
            @ref sip_accept "Accept" headers in the request (if needed)
	- Processing notifications for "presence" event
	  - Handling of presence information in notifications
    </td>
</tr>

<a name="3857"></a> <a name="3858"></a>
<tr valign=top>
    <th align="left">
	@RFC3857: "winfo" event template package<br>
	@RFC3858: winfo format
    </th>
    <td>
	Sofia-SIP supports <a href="#3265">generic SIP event support</a> for
	subscribing SIP event packages and receiving notifications for them.
	Subscriptions are refreshed before expiration when needed and
	subscriptions are terminated on request. Sofia-SIP takes care of
        notified subscription states.
    </td>
    <td>
        Application must take care of:
	- Generating subscriptions for winfo events
          - Including correct @ref sip_event "Event" and
            @ref sip_accept "Accept" headers in the request (if needed)
	- Processing notifications for winfo events:
	  - Processing watcherinfo XML documents
    </td>
</tr>

<a name="3860"></a>
<tr valign=top>
    <th align="left">
	@RFC3860: Common Profile for IM
    </th>
    <td>
	Sofia-SIP supports handling of any URI type. Sofia-SIP parses "im:"
        URIs.
    </td>
    <td>
        Application must take care of:
	- resolving the "im:" URI
    </td>
</tr>

<a name="3891"></a>
<tr valign=top>
    <th align="left">
	@RFC3891: Replaces
    </th>
    <td>
	@ref sip_replaces "Replaces" header is explicitly supported
	(generating, parsing and syntax checking).
    </td>
    <td>
        Application must take care of:
	- generating @ref sip_replaces "Replaces" header from a dialog and
          matching a dialog with a Replaces header received
    </td>
</tr>

<a name="3892"></a>
<tr valign=top>
    <th align="left">
	@RFC3892: Referred-By
    </th>
    <td>
	@ref sip_referred_by "Referred-By" header is explicitly supported
	(generating, parsing and syntax checking).

	Referred-by token can be sent and received in
	text-based SIP message body.
    </td>
    <td>
        Application must take care of:
	- Generating or processing @ref sip_referred_by "Referred-By" headers
	- Generating (and encrypting) or verifying (and decrypting) of
	  Referred-by tokens
    </td>
</tr>

<a name="3903"></a>
<tr valign=top>
    <th align="left">
	@RFC3903: PUBLISH