Loading...
Searching...
No Matches
SIP and SDP Protocol Features in Sofia-SIP

This document describes how Sofia-SIP stack supports specifications listed below.

RFC 3261
RFC 2617
RFC 3262
RFC 3263
RFC 3265
RFC 2806
RFC 2976
RFC 3311
RFC 3313
RFC 3323
RFC 3326
RFC 3325
RFC 3327

RFC 3329
RFC 3361
RFC 3420
RFC 3428
RFC 3486
RFC 3515
RFC 3581
RFC 3608
RFC 3680
RFC 3824
RFC 3840
RFC 3841
RFC 3842

RFC 3856
RFC 3857
RFC 3858
RFC 3859
RFC 3860
RFC 3891
RFC 3892
RFC 3903
RFC 4028
RFC 4168
RFC 4320
RFC 4488
RFC 5057

RFC 4566
RFC 2327
RFC 3264
RFC 3266
RFC 3312
RFC 3388
RFC 3407
RFC 3524
RFC 3551
RFC 3556
RFC 3605
RFC 3890

Feature | Supported | Notes
--- | --- | ---

RFC 3261: Basic SIP Protocol

The SIP registration and dialog level implementation enables the application to operate as a SIP UA, SIP proxy or a redirect server according to the RFC 3261.

The RFC 3261 functionality is divided into five layers:

1. message syntax and encoding
2. transport
3. transaction
4. transaction user (UAS and UAC cores, proxy core)
5. SIP elements: user agent client and server, proxies, registrars

RFC 3261 Sections 19 and 20:
Syntax and encoding

The supported RFC 3261 methods are: REGISTER, OPTIONS, INVITE, ACK, CANCEL, BYE, as well as extension methods INFO, PRACK, SUBSCRIBE, NOTIFY, UPDATE, MESSAGE, REFER, and PUBLISH.

Sofia-SIP supports the following SIP headers as specified in RFC 3261 or its extensions (generating, parsing and syntax checking):

Accept, Accept-Encoding, Accept-Language, Alert-Info (extension in 1.12.7), Allow, Authentication-Info, Authorization, Call-ID ("i"), Call-Info, Contact ("m"), Content-Disposition, Content-Encoding ("e"), Content-Language, Content-Length ("l"), Content-Type ("c"), CSeq, Date, Error-Info, Expires, From ("f"), In-Reply-To, Max-Forwards, Min-Expires, MIME-Version, Organization, P-Asserted-Identity (extension in 1.12.7), P-Preferred-Identity (extension in 1.12.7), Priority, Proxy-Authenticate, Proxy-Authorization, Proxy-Require, Record-Route, Refer-Sub (1.12.5), Remote-Party-ID (extension in 1.12.7), Reply-To (extension in 1.12.7), Require, Retry-After, Route, Server, Subject ("s"), Supported ("k"), Timestamp, To ("t"), Unsupported, User-Agent, Via ("v"), Warning, and WWW-Authenticate.

Unknown headers (extension headers) are supported and can be passed to/received from application as name-value pairs.

It is possible to extend SIP parser in run-time with header-specific parsers.

- Automatic escaping of reserved characters has not been implemented.
- Using NUL (zero byte) in double-quoted strings has not been implemented

RFC 3261 Section 18:
UDP and TCP transports

UDP and TCP on both IP4 and IP6 are supported.

The UDP size limit of 1300 bytes is enforced by default. If limit is exceeded, TCP is tried instead. If TCP connection is refused, UDP is tried if message size is less than 64 kilobytes. Limit is adjustable via parameter NTATAG_UDP_MTU().

TCP connections are reused by client. However, server closes connections after idle time of 30 minutes (by default). The idle time limit is adjustable with TPTAG_IDLE() (given as argument to nta_agent_add_tport() or nta_agent_create()).

Server tries to use same TCP connection to return response as the request was received.

Only one SIP message is accepted per UDP message, as per RFC 3261.

There is experimental support for SCTP, too.

RFC 3261 Section 17:
Transactions

Transaction state engines function as specified in RFC 3261 section

1. There is special handling of methods INVITE, ACK, and CANCEL. There are two modes for transaction state engines, User-Agent and Proxy modes.

Default values for SIP timers are those specified by RFC 3261. The values for T1, T1x64, T2 and T4 can be changed via configuration tags defined in <sofia-sip/nta_tag.h>.

The SIP timer C is implemented from 1.12.7. Also, its value can be changed via configuration tag NTATAG_TIMER_C() defined in <sofia-sip/nta_tag.h>.

RFC 3261 Section 26:
Security

TLS and SIPS URIs has been implemented. Currently, TLS does not require certificate from client nor it does check it if one is provided.

Missing:

- Authorizing connections with TLS certificates
- S/MIME

RFC 2617: HTTP Digest Authentication

Sofia-SIP includes authentication client and server modules implementing HTTP Digest authentication.

HTTP Digest is a simple challenge-response authentication scheme defined in RFC 2617 based on the UA sending a checksum calculated over specific values in response to a challenge sent by the server (proxy or UA).

    Checksum calculation supports MD5 (<a href="http://tools.ietf.org/html1321">RFC 1321</a>). The algorithm for
    calculating MD5 digest hash can be MD5, MD5sess or be
    <a href="http://tools.ietf.org/html2069">RFC 2069</a>-compatible algorithm. The quality-of-protection (qop)
    parameters "auth", "auth-int" and none (missing) are supported. The
    "opaque" parameter is supported.

The SIP authentication headers supported (generating, parsing and syntax checking) are: Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authentication-Info, Proxy-Authorization, and WWW-Authenticate.

SIP interface to the modules is implemented as defined in RFC 3261 (sections 8.1.3.5, 22.2, 22.3, 22.4).

An RFC 2617 header Proxy-Authentication-Info is not listed in RFC 3261 but it is nevertheless supported by Sofia-SIP.

Missing:

- Using nextnonce

Mutual authentication

RFC 3262: PRACK and 100rel

PRACK method is supported within dialog as defined in RFC3262. Semantics of reliable provisional responses are supported:

- including 100rel Required header in provisional responses if request had 100rel

generation of PRACK based on 100rel option tag in Require header of a provisional response, and

- automatic re-transmission of provisional responses.

The SIP headers supported (generating, parsing and syntax checking) are RSeq and RAck.

RFC 3263: Locating SIP Servers

Support for SIP server address resolution from SIP or SIPS URI using NAPTR, SRV, A or AAAA records in DNS as defined in RFC 3263.

- Resolving any other types of URIs than SIP or SIPS URIs, e.g., IM: or PRES: URIs.

RFC 3265: SIP Event Notifications

SIP extensions for subscribing and processing asynchronous event notifications as defined in RFC 3265.

Includes dialog level support for sending and refreshing SUBSCRIBE and receiving NOTIFY messages.

The SIP headers explicitly supported (generating, parsing and syntax checking) are Event ("o"), Allow-Events, and Subscription-State

Note: currently there is no support for forked SUBSCRIBE requests.

Application must take care of:

- Subscribing, generating or processing specific event types and interpreting the content of event data is up to application

RFC 2806: tel URI

Sofia-SIP supports handling of any URI type. Sofia-SIP parses tel: URIs.

Missing:

- Resolving the tel: URIs

RFC 2976: INFO

INFO method is supported within a dialog natively.

Not implemented:

- Generating or processing contents of INFO requests

RFC 3311: UPDATE

UPDATE method as defined in RFC3311. UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) even within early dialogs.

Offer-Answer negotiation with UPDATE is implemented in nua.

Application must take care of:

- Initiating UPDATE requests

RFC 3313: Media Authentication

Sofia-SIP provides generic support for extension headers and parameters. P-Media-Authorization header is supported as an extension header.

Application must take care of:

- Passing the authorization token to QoS reservation request

RFC 3323: 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, Contact and 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.,

Anonymous <sip:anonymous@example-email.address.hidden>

.

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.

RFC 3326: Reason

Sofia-SIP supports Reason header (generating, parsing and syntax checking).

Application must take care of:

- Generating or processing Reason headers

RFC 3325: Asserted Identity

Sofia-SIP supports P-Asserted-Identity and P-Preferred-Identity headers (generating, parsing and syntax checking). Also the non-standard header Remote-Party-ID is supported.

Since
  New in 1.12.7.

Not implemented:

- id privacy

Recognizing trust domains and enforcing handling of headers based on those

RFC 3327: Path

User-agent engine can add "path" option tag to Supported header of REGISTER requests.

Sofia-SIP explicitly supports Path header (generating, parsing and syntax checking).

RFC 3329: Security Agreement

Some support of the SIP Security Mechanism Agreement procedures. The client is able to insert Security-Client and Security-Verify header with fake d-ver value.

Sofia-SIP explicitly supports (generating, parsing and syntax checking) Security-Client, Security-Server, and Security-Verify headers.

Security-mechanism supported is "digest".

Correct d-ver value is not calculated.

RFC 3361: DHCPv4 option for locating SIP servers.

Sofia-SIP supports outbound proxy.

Application must take care of:

- passing outbound proxy name or address from DHCP client to Sofia-SIP stack.

RFC 3420: message/sipfrag

Sofia-SIP passes the received SIP message headers to application which can create a message/sipfrag payload.

Application must take care of:

- processing the SIP message fragments

RFC 3428: MESSAGE

MESSAGE method is supported natively.

RFC 3486: Compressing SIP

Sofia-SIP provides support for using comp=sigcomp parameters in Via header and SIP URIs, indicating support for compression.

SigComp itself is not supported.

RFC 3515: REFER

REFER method is supported natively. Sofia-SIP processes incoming REFER requests and generates NOTIFY with correct 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) Refer-To ("r") SIP header.

See also support for RFC 3891 and RFC 3892.

RFC 3608: Service-Route

Sofia-SIP supports 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 Service-Route header.

The SIP header explicitly supported (generating, parsing and syntax checking) is Service-Route.

RFC 3680: "reg" event

Sofia-SIP supports generic SIP event support 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.

Application must take care of:

- Generating subscriptions for "reg" event
- Processing notifications for "reg" event
  - Handling of XML document in notifications

RFC 3824: ENUM

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.

Stack can not resolve E.164 number to address of next hop. A proxy in the network must resolve E.164 numbers with ENUM.

RFC 3840: Callee Capabilities

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.

Application must take care of:

- Processing the feature parameters received in the Contact header

RFC 3841: Caller Preferences

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: Request-Disposition ("d"), Accept-Contact ("a"), Reject-Contact ("j"),

Application must take care of:

- UAS processing incoming Accept-Contact or Reject-Contact headers

RFC 3842: Message waiting event

Sofia-SIP supports generic SIP event support 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.

Application must take care of:

- Generating subscriptions for "message-summary" event
  - Including correct Event and Accept headers in the request (if needed)
- Processing notifications for "message-summary" event
  - Handling of summary information in notifications

RFC 3856: Presence
RFC 3859: Common Profile for Presence

Sofia-SIP supports generic SIP event support 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.

Application must take care of:

- Generating subscriptions for "presence" event
  - Including correct Event and Accept headers in the request (if needed)
- Processing notifications for "presence" event
  - Handling of presence information in notifications

RFC 3857: "winfo" event template package
RFC 3858: winfo format

Sofia-SIP supports generic SIP event support 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.

Application must take care of:

- Generating subscriptions for winfo events
  - Including correct Event and Accept headers in the request (if needed)
- Processing notifications for winfo events:
  - Processing watcherinfo XML documents

RFC 3860: Common Profile for IM

Sofia-SIP supports handling of any URI type. Sofia-SIP parses "im:" URIs.

Application must take care of:

- resolving the "im:" URI

RFC 3891: Replaces

Replaces header is explicitly supported (generating, parsing and syntax checking).

Application must take care of:

- generating Replaces header from a dialog and matching a dialog with a Replaces header received

RFC 3892: 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.

Application must take care of:

- Generating or processing Referred-By headers
- Generating (and encrypting) or verifying (and decrypting) of Referred-by tokens

RFC 3903: PUBLISH

PUBLISH method is supported natively. The SIP headers explicitly supported (generating, parsing and syntax checking) are SIP-ETag and SIP-If-Match.

The user-agent engine keep published data refreshed until nua_unpublish() is called.

Application must take care of:

- Including correct Event in the request
- Permanently storing SIP-ETag

RFC 4028: Session Timers

The SIP session-timer ("timer") extension is supported.

    The session-expires value and refreshing party is negotiated in

user-agent engine. 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 BYE request.

    The SIP headers explicitly supported (generating, parsing and

syntax checking) are Session-Expires ("x") and Min-SE.

RFC 4168: SCTP as Transport for SIP

The transport=sctp URI parameter is supported. The SCTP transport protocol is supported as experimental. It is enabled with configure script argument –enable-sctp.

The framing of SIP messages over SCTP is not specified clearly in RFC 4168. It is possible to send SIP messages smaller than 64K over SCTP.

RFC 4320: Actions Addressing Identified Issues with SIP's Non-INVITE Transaction

The action 1 (make the best use of provisional responses) is supported when NTATAG_EXTRA_100(1) is used with nua_create() or nta_agent_create(). The 100 Trying provisional response is sent after T2 is expired or when a retransmission is received after T2/2 after the initial request.

The action 2 (remove the useless late-response storm) is supported by default. The 408 timeout response is not forwarded by default (it's forwarding can be enabled with NTATAG_PASS_408(1), however).

Application must include NTATAG_EXTRA_100(1) with nua_create() or nta_agent_create() tags.

RFC 4488: Suppression of REFER Implicit Subscription

Sofia-SIP supports Refer-Sub header (generating, parsing and syntax checking).

    The implicit subscription is suppressed by @ref nua_index "nua", if the @ref sip_refer_sub "Refer-Sub":
    true header is included in the REFER

request (on server side) or response (on client side).

Since
  New in 1.12.5

The REFER client application must include SIPTAG_REFER_SUB_STR("true") in the nua_refer() tags.

RFC 5057: Multiple Dialog Usages in SIP

Sofia-SIP provides function sip_response_terminates_dialog() that can be used to determine the effect of error response with dialog.

The nua UA engine uses sip_response_terminates_dialog().

The client application must either use NUA or sip_response_terminates_dialog().

Feature | Supported | Notes
--- | --- | ---

RFC 4566: SDP: Session Description Protocol

Generic support (generating, parsing and syntax checking) for SDP. The SDP v=, o=, c=, b=, t=, r=, z=, k=, a=, and 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", a=rtpmap, and "a=fmtp" are parsed.

The implementation partially implements RFC 4566. Note that definition of 'token' was updated in RFC 4566 and the parser has not been updated yet.

RFC 4566 obsoletes

- RFC 2327: SDP (Session Description Protocol)
- RFC 3266: IP6 in SDP

RFC 3264: SDP Offer/Answer Negotiation

Generating and processing offers or answers.

- "a=fmtp" parameters are not taken into account when generating or processing answer

RFC 3312: Preconditions

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

    Sofia-SIP supports handling SIP feature tags in

Proxy-Require, Require, Supported ("k"), and Unsupported header.

Application must take care of:

- Semantics and handling of preconditions
- Reservation of resources

RFC 3388: Grouping of Media Lines

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

RFC 3388 defines mid, group, LS and FID are predefined strings to be used within attribute line

Application must take care of:

- Generating or processing the attribute lines
- Grouping the media for transport accordingly

RFC 3407: Capability Declaration

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

Application must take care of:

- Defining sqn, cdsc, cpar etc. strings needed in a= line
- Generating or processing the attribute lines
- Capability negotiation itself

RFC 3524: SRF

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

Application must take care of:

- Defining SRF string needed in a= line
- Generating or processing the attribute lines

RFC 3551: RTP/AVP

Sofia-SIP recognizes the RTP payload types for well-known audio and video codecs defined in RFC 3551.

Application must take care of:

- Audio or video processing
  - Generating a=rtpmap or a=fmtp lines when needed

RFC 3556: Bandwidth

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

Application must take care of:

- Generating or processing RS and RR bandwidth modifiers
- Semantics of bandwidth allocation

RFC 3605: RTCP attribute

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

Application must take care of:

- Discovering port numbers
- Generating or processing the RTCP attribute lines

RFC 3890: TIAS

Sofia-SIP provides generic support for attribute lines that conform to SDP syntax.

Application must take care of:

- Generating or processing TIAS bandwidth modifiers
- Generating or processing the maxprate attribute lines

Sofia-SIP 1.12.11devel - Copyright (C) 2006 Nokia Corporation. All rights reserved. Licensed under the terms of the GNU Lesser General Public License.