Automatic escaping of reserved characters has not been implemented.未实现保留字符的自动转义（这么解释？）。
Using NUL (zero byte) in double-quoted strings has not been implemented未实现双引号间无任何字符的空字串（这么解释？）。

特性

RFC 3261 18章:UDP和TCP传输

已支持

基于IP4和IP6的UDP和TCP均支持。

1300字节的UDP包大小限制缺省被强制执行。如果超过这个上限，选用TCP。如果TCP连接被拒绝，且消息大小小于64千字节，试着使用UDP连接。可shiyongNTATAG_UDP_MTU()来调整这个数值。

在客户端TCP连接会被重复使用。然而在服务端缺省在30分钟的空闲之后会关闭TCP连接。空闲时长上限可通过TPTAG_IDLE()来调整（作为参数提供给nta_agent_add_tport()或nta_agent_create()）。

服务端会使用收到消息的同一个TCP连接发送响应消息。

每个UDP消息包中只能包括一个SIP消息。as per RFC 3261.（这个该怎么翻译？）

注意

对SCTP也有着实验性的支持。

特性

RFC 3261 17章：事务

已支持

RFC 3261第十七章描述了事物状态引擎功能。针对INVITE、ACK和CANCEL方法会有特殊的处理。事物状态引擎分两种模式：用户模式和代理模式。

RFC 3261中定义了SIP定时器缺省值。T1，64倍的T1，T2和T4的值可通过<sofia-sip/nta_tag.h>头文件中的配置tags修改。

SIP定时器C的实线可参考：1.12.7。同样，它的值可通过<sofia_sip/nta_tag.h>头文件中定义的NTATAG_TIMER_C() tag函数修改。

注意

特性

RFC 3261 26章：安全

已支持

实现了TLS和SIPS的URIs。当前，TLS方式并不需要证书，即便提供了也不会检查。

注意

未实现：
- 使用TLS证书验证连接
- S/MIME（怎么翻译？）
特性

RFC 2617：HTTP摘要式身份认证

已支持

Sofia-SIP包括HTTP摘要式身份认证的客户端和服务端认证模块（这么翻译？）。 includes authentication client and server modules implementing HTTP Digest authentication.

HTTP Digest是一个简单的挑战-响应认证体系，由RFC2617定义。UA针对服务端发来的挑战发送依据特定值计算出的校验码（这么翻译？）。based on the UA sending a checksum calculated over specific values in response to a challenge sent by the server (proxy or UA).

校验码计算支持MD5（RFC 1321）。计算MD5摘要式哈希表的算法可以是MD5，MD5sess或者是RFC 2069兼容的算法。"auth"，"auth-int"和none（不出现）这三项qop参数值都支持。支持“opaque”参数。

支持的SIP认证头域（生成、解析和语法检查）有：Authorization，Authentication-Info，Proxy-Authenticate，Proxy-Authentication-Info,Proxy-Authorization，和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).

RFC 2617的头Proxy-Authentication-Info并没有出现在RFC 3261中，但Sofia-SIP仍然支持它。

注意

未实现：
- Using nextnonce
- Mutual authentication
特性

RFC 3262：PRACK和100rel

已支持

支持RFC3262定义的会话中PRACK方法。支持临时应答可靠性语义：:
- 如果请求中包含100rel在临时响应消息中包含100rel头域
- 如果临时响应消息的Require头域包含100rel可选标签则生成PRACK消息
- 自动重发临时响应消息
支持RSeq和RAck SIP头域（生成，解析和语法检查）。

注意

扩展阅读：http://blog.chinaunix.net/uid-790245-id-2037585.html，http://blog.youkuaiyun.com/wind19/article/details/7440839。

特性

RFC 3263：定位SIP服务器

已支持

从SIP或SIPS URI中解析出SIP服务器地址，使用DNS中的NAPTR，SRV，A或AAAA记录。Support for SIP server address resolution from SIP or SIPS URI using NAPTR, SRV, A or AAAA records in DNS as defined inRFC 3263.

注意

解析除了SIP或SIPS外其他任何URIs，例如，IM:或PRES:URIS。Resolving any other types of URIs than SIP or SIPS URIs, e.g., IM: or PRES: URIs.

特性

RFC 3265：SIP事件通知

已支持

RFC 3265中出现的订阅、处理异步事件通知的SIP扩展。SIP extensions for subscribing and processing asynchronous event notifications as defined inRFC 3265.

包括会话层的发送刷新SUBSCRIBE和接收NOTIFY消息。Includes dialog level support for sending and refreshing SUBSCRIBE and receiving NOTIFY messages.

明确支持（生成、解析和语法检查）的SIP头域有Event（“o”），Allow-Events和Subscription-State。The SIP headers explicitly supported (generating, parsing and syntax checking) areEvent ("o"),Allow-Events, andSubscription-State

注意：当前不支持衍生的（这么翻译？）SUBSCRIBE请求。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支持任何URI类型的处理。Sofia-SIP可以解析tel:URIs结构。

注意

缺少：
- tel: URIs地址解析
扩展阅读：http://blog.youkuaiyun.com/jxhnuaa/article/details/3254566。

特性

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 anextension 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 andVia 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 headerRemote-Party-ID is supported.

Since:
New in 1.12.7.

注意

ot 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 faked-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 correctEvent 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 inService-Route header.

The SIP header explicitly supported (generating, parsing and syntax checking) isService-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) areSIP-ETag andSIP-If-Match.

The user-agent engine keep published data refreshed untilnua_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 aBYE request.

The SIP headers explicitly supported (generating, parsing and syntax checking) areSession-Expires ("x") andMin-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 inRFC 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 whenNTATAG_EXTRA_100(1) is used withnua_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 withNTATAG_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).

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().

特性

RFC 4566: SDP: Session Description Protocol

已支持

Generic support (generating, parsing and syntax checking) for SDP. The SDPv=,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 inRFC 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

注意

ication 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