This document describes how Sofia-SIP stack supports specifications listed below.
| 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:
|
|
| 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. |
|
| 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 17. 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:
|
| 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 (RFC 1321). The algorithm for calculating MD5 digest hash can be MD5, MD5sess or be RFC 2069-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:
|
| RFC 3262: PRACK and 100rel | PRACK method is supported within dialog as defined in RFC3262. Semantics of reliable provisional responses are supported:
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. |
|
| 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:
|
| RFC 2806: tel URI | Sofia-SIP supports handling of any URI type. Sofia-SIP parses tel: URIs. | Missing:
|
| RFC 2976: INFO | INFO method is supported within a dialog natively. | Not implemented:
|
| 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:
|
| 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:
|
| 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:
|
| RFC 3326: Reason | Sofia-SIP supports Reason header (generating, parsing and syntax checking). | Application must take care of:
|
| 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.
| Not implemented:
|
| 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:
|
| 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:
|
| 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. |
|
| 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:
|
| 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:
|
| 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:
|
| 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:
|
| 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:
|
| 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:
|
| RFC 3860: Common Profile for IM | Sofia-SIP supports handling of any URI type. Sofia-SIP parses "im:" URIs. | Application must take care of:
|
| RFC 3891: Replaces | Replaces header is explicitly supported (generating, parsing and syntax checking). | Application must take care of:
|
| 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:
|
| 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: |
| 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 nua, if the Refer-Sub: true header is included in the REFER request (on server side) or response (on client side).
| 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 3264: SDP Offer/Answer Negotiation | Generating and processing offers or answers. |
|
| 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:
|
| 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:
|
| RFC 3407: Capability Declaration | Sofia-SIP provides generic support for attribute lines that conform to SDP syntax. | Application must take care of:
|
| RFC 3524: SRF | Sofia-SIP provides generic support for attribute lines that conform to SDP syntax. | Application must take care of:
|
| 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:
|
| RFC 3556: Bandwidth | Sofia-SIP provides generic support for attribute lines that conform to SDP syntax. | Application must take care of:
|
| RFC 3605: RTCP attribute | Sofia-SIP provides generic support for attribute lines that conform to SDP syntax. | Application must take care of:
|
| RFC 3890: TIAS | Sofia-SIP provides generic support for attribute lines that conform to SDP syntax. | Application must take care of:
|
