conformance.docs

Internet Phone, Chat, Conferencing

</tr>

<tr valign=top>
    <th align="left">
	<a name="3515"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3608"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3680"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3824"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3840"></a>
	@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>


<tr valign=top>
    <th align="left">
	<a name="3841"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3842"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3856"></a>
	@RFC3856: 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>

<tr valign=top>
    <th align="left">
	<a name="3857"></a> <a name="3858"></a>
	@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 watcherxinfo XML documents
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3891"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3892"></a>
	@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>

<tr valign=top>
    <th align="left">
	<a name="3903"></a>
	@RFC3903: PUBLISH
    </th>
    <td>
	PUBLISH method is supported natively. The SIP headers
	explicitly supported (generating, parsing and syntax checking) are
	@ref sip_etag "SIP-ETag" and @ref sip_if_match "SIP-If-Match".

	The <a href="nua/index.html">user-agent engine</a> keep published
	data refreshed until nua_unpublish() is called.
    </td>
    <td>
        Application must take care of:
        - Including correct @ref sip_event "Event" in the request
        - Permanently storing SIP-ETag
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="4028"></a>
	@RFC4028: Session Timers
    </th>
    <td>
	The SIP session-timer ("timer") extension is supported.

        The session-expires value and refreshing party is negotiated in
	<a href="nua/index.html">user-agent engine</a>. When user-agent
	engine is responsible for refreshes, it will initiate re-INVITE or
	UPDATE transaction at regular intervals. If there has been no SIP
	activity in session during the refresh period, it will try to
	automatically terminate the call by sending a @b BYE request.

        The SIP headers explicitly supported (generating, parsing and
	syntax checking) are @ref sip_session_expires "Session-Expires" ("x") and
	@ref sip_min_se "Min-SE".
    </td>
    <td>
	&nbsp;
    </td>
</tr>
</table>

<table border=1 cellpadding=4 cellspacing=0>
<tr>
   <th>Feature</th>
   <th>Supported</td>
   <th>Notes</td>
</tr>

<tr valign=top>
    <th align="left" align="left">
	<a name="2327"></a>
	@RFC2327: SDP (Session Description Protocol)
    </th>
    <td>
	Generic support (generating, parsing and syntax checking) for SDP.
	The SDP
        @ref sdp_version_t "v=",
        @ref sdp_origin_t "o=",
	@ref sdp_connection_t "c=",
	@ref sdp_bandwidth_t "b=",
	@ref sdp_time_t "t=",
	@ref sdp_repeat_t "r=",
	@ref sdp_zone_t "z=",
	@ref sdp_key_t "k=",
	@ref sdp_attribute_t "a=", and
	@ref sdp_media_t "m="
        lines are separated and parsed. The "e=", "p=", "s=", and "i=" lines
	are separated.

	The attributes "a=sendrecv", "a=sendonly", "a=recvonly",
	"a=inactive", @ref sdp_rtpmap_s "a=rtpmap", and "a=fmtp" are parsed.

	The implementation tries to follow draft-ietf-mmusic-sdp-new-25,
	draft Internet Standard for SDP in progress.
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3264"></a>
	@RFC3264: SDP Offer/Answer Negotiation
    </th>
    <td>
	Generating and processing offers or answers.
    </td>
    <td>
	- "a=fmtp" parameters are not taken into account
          when generating or processing answer
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3266"></a>
	@RFC3266: IP6 in SDP
    </th>
    <td>
	Representation of IP6 addresses within SDP message.
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3312"></a>
	@RFC3312: Preconditions
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.

        Sofia-SIP supports handling SIP feature tags in
	@ref sip_proxy_require "Proxy-Require",
        @ref sip_require "Require",
        @ref sip_supported "Supported" ("k"),
        and
        @ref sip_unsupported "Unsupported" header.
    </td>
    <td>
	Application must take care of:
	- Semantics and handling of preconditions
	- Reservation of resources
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3388"></a>
	@RFC3388: Grouping of Media Lines
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.

	@RFC3388 defines mid, group, LS and FID are predefined strings to be
	used within attribute line
    </td>
    <td>
        Application must take care of:
	- Generating or processing the attribute lines
	- Grouping the media for transport accordingly
    </td>
</tr>


<tr valign=top>
    <th align="left">
	<a name="3407"></a>
	@RFC3407: Capability Declaration
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.
    </td>
    <td>
        Application must take care of:
	- Defining sqn, cdsc, cpar etc. strings needed in a= line
	- Generating or processing the attribute lines
	- Capability negotiation itself
    </td>
</tr>


<tr valign=top>
    <th align="left">
	<a name="3524"></a>
	@RFC3524: SRF
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.
    </td>
    <td>
        Application must take care of:
	- Defining SRF string needed in a= line
	- Generating or processing the attribute lines
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3556"></a>
	@RFC3556: Bandwidth
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.
    </td>
    <td>
        Application must take care of:
	- Generating or processing RS and RR bandwidth modifiers
	- Semantics of bandwidth allocation
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3605"></a>
	@RFC3605: RTCP attribute
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.
    </td>
    <td>
        Application must take care of:
	- Discovering port numbers
	- Generating or processing the RTCP attribute lines
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3890"></a>
	@RFC3890: TIAS
    </th>
    <td>
	Sofia-SIP provides <a href="#2616">generic support</a> for attribute
	lines that conform to SDP syntax.
    </td>
    <td>
        Application must take care of:
	- Generating or processing TIAS bandwidth modifiers
	- Generating or processing the maxprate attribute lines
    </td>
</tr>

</table>

*/

/* Overflow:

<tr valign=top>
    <th align="left">
	<a name="3320"></a>
	@RFC3320: SigComp
    </th>
    <td>
    	Support for using SigComp for compression and
	decompression of SIP/SDP messages. By default, dynamic
	compression is used.

	Decompression using UDVM
    </td>
    <td>
	&nbsp;
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3321"></a>
	@RFC3321: SigComp Extended operations
    </th>
    <td>
	Support for SigComp extended operations.
    </td>
    <td>
	- Explicit Acknowledgment Scheme
	- Shared Compression
	- Checkpoint State
	- Implicit Deletion for Dictionary Update
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3325"></a>
	@RFC3325: Asserted Identity
    </th>
    <td>
	Explicit support (generating, parsing and syntax checking) for the
	following SIP headers: P-Asserted-Identity, P-Preferred-Identity
    </td>
    <td>
	- Recognizing trust domains and enforcing handling of headers
	  based on those
    </td>
</tr>

<tr valign=top>
    <th align="left">
	<a name="3485"></a>
	@RFC3485: SIP/SDP Dictionary
    </th>
    <td>
	Support for SigComp static compression using SIP/SDP
	dictionary.
    </td>
    <td>
	&nbsp;
    </td>
</tr>




	- Implicitly registered user identities

<tr valign=top>
    <th align="left">
	<a name="3959"></a>
	@RFC3959: early-session
    </th>
    <td>
	Early-session value can be used within Content-Disposition,
	Supported and Require headers.
    </td>
    <td>
	- Generating of Content-Disposition, Supported and Require
	- Handling of multipart bodies with early and session SDP
    </td>
</tr>


*/