SIP Interface Specifications¶

This document is a review of all the SIP related RFCs referenced by IMS (in particular TS 24.229 Rel 10), particularly how they relate to Clearwater’s SIP support. The bulk of the document goes through the RFCs grouped in the following 4 categories.

RFCs already supported by Clearwater (at least sufficient for IMS compliance for Clearwater as a combined P/I/S-CSCF/BGCF/IBCF).
RFCs partially supported by Clearwater.
RFCs that are relevant to Clearwater but not currently supported.
RFCs relevant to media processing, which Clearwater doesn’t currently need to handle as it is not involved in the media path.
RFCs that are not relevant to Clearwater.

Supported¶

The following RFCs are already supported by Clearwater. Note that a number of these are supported simply because they require no active function from SIP proxies other than forwarding headers unchanged.

Basic SIP (RFC 3261)¶

This covers the basic SIP protocol including
- the 6 basic methods (ACK, BYE, CANCEL, INVITE, OPTIONS and REGISTER)
- the 44 basic headers
- the transaction and dialog state machines
- the function of UACs, UASs, stateful and stateless proxies, and registrars
- basic and digest security
- transport over UDP and TCP.
Clearwater supports this RFC.

UPDATE method (RFC 3311)¶

Defines UPDATE method used to update session parameters (so can be used as an alternative to reINVITE as a keepalive, for media renegotiation or to signal successful resource reservation). Often used by ICE enabled endpoints to change media path once ICE probing phase has completed.
Supported transparently by Clearwater.

Privacy header (RFC 3323)¶

Required for privacy service.
Clearwater supports this header.

P-Asserted-Identity and P-Preferred-Identity headers (RFC 3325)¶

Defines headers that allow a UE to select which identity it wants to use on a call-by-call basis. Ties in with authentication and the P-Associated-URIs header defined in RFC 3455 (see below).
Clearwater supports these headers.

Path header (RFC 3327)¶

Defines handling of registrations from devices which are not adjacent (in SIP routing terms) to the registrar.
Supported by Clearwater.

message/sipfrag MIME type (RFC 3420)¶

RFC 3420 defines an encoding for transporting MIME or S/MIME encoded SIP message fragments in the body of a SIP message. Use cases for this include status NOTIFYs sent during REFER processing which signal the status of the referral to the referee.
Support for this is mandatory according to TS 24.229, but it does not describe any particular use cases.
Transparent to proxy components, so supported by Clearwater.

P-Access-Network-Info, P-Associated-URI, P-Called-Party-ID, P-Charging-Function-Address, P-Charging-Vector and P-Visited-Network-ID headers (RFC 3455)¶

Defines various private headers specifically for IMS.
P-Access-Network-Info is added to incoming messages by the UE or the P-CSCF to provide information about the access network and possibly the UEs location within the network (for example cell). IMS specifications talk about various uses for this information, including routing emergency calls, an alternative to phone-context for interpreting dialled digits, determining the security scheme. This header is supported by Clearwater.
P-Associated-URI is returned by registrar to include the list of alternative user identities defined for the IMS subscription. This header is supported by Clearwater.
P-Called-Party-ID is added to a SIP request by an IMS network to ensure the called UE knows which of the user identities within the IMS subscription was actually called. This header is supported by Clearwater.
P-Charging-Function-Address and P-Charging-Vector headers are related to billing, and are supported by Clearwater.
P-Visited-Network-ID is used when roaming to identify the network the user has roamed to. The specs say it is a free-form string, and should be used to check that there is a roaming agreement in place. This header is supported by Clearwater.

Symmetric SIP response routing (RFC 3581)¶

Defines how SIP responses should be routed to ensure they traverse NAT pinholes.
Mandatory for IMS proxy components.
Supported by Clearwater nodes.

Service-Route header (RFC 3608)¶

In IMS an S-CSCF includes Service-Route header on REGISTER responses, so UE can use to construct Route headers to ensure subsequent requests get to the appropriate S-CSCF.
Optional according to TS 24.229(http://www.3gpp.org/ftp/Specs/html-info/24229.htm).
This header is supported by Clearwater.

ENUM (RFC 3761 and RFC 4769)¶

Defines a mechanism for using DNS look-ups to translate telephone numbers into SIP URIs. (RFC 3761 defines ENUM, RFC 4769 contains IANA registrations for ENUM data.)
IMS specifies that ENUM is one mechanisms an S-CSCF can use to translate non-routable URIs (either Tel URIs or SIP URIs encoding a phone number) into a globally routable URI (one where the domain name/IP address portion of the URI can safely be used to route the message towards its destination).
Clearwater supports this through function in Sprout.

Event package for MWI (RFC 3842)¶

Defines an event package for notifying UAs of message waiting.
Required for UEs and ASs implementing MWI services, transparent to proxy components.
Transparent to proxies, so already supported by Clearwater.

Presence event package (RFC 3856)¶

Defines an event package for monitoring user presence.
Required for UEs supporting presence and presence servers.
Transparent to proxies, so supported by Clearwater.

Watcher event template package (RFC 3857)¶

Defines an event package that can be used to subscribe to the list of watchers for another event type.
IMS mandates support for this package for subscribing to the list of watchers of a particular presentity, so support is only applicable for SIP UEs supporting presence and presence application servers.
Transparent to proxies, so supported by Clearwater.

Session-expiry (RFC 4028)¶

Covers periodic reINVITE or UPDATE messages used to allow UEs or call stateful proxies to detect when sessions have ended. Includes Min-SE and Session-Expires headers, which are used to negotiate the frequency of keepalives.
Clearwater supports session-expiry as a proxy per section 8 of the RFC. It does not have a minimum acceptable session interval, so does not make use of the Min-SE header, though does honor it.
Clearwater requests a session interval of 10 minutes (or as close to 10 minutes as possible given pre-existing headers) in order to properly perform session-based billing.

Early session disposition type (RFC 3959)¶

Defines a new value for the Content-Disposition header to indicate when SDP negotiation applies to early media.
Optional according to TS 24.229.
Transparent to proxies so supported by Clearwater.

Dialog events (RFC 4235)¶

Event package for dialog state.
In TS 24.229 only seems to be relevant to E-CSCF and LRF functions.
Transparent to proxies, so supported by Clearwater.

MRFC control (RFC 4240, RFC 5552, RFC 6230, RFC 6231, RFC 6505)¶

These RFCs define three different ways of controlling the function of an MRFC from an AS. RFC 4240 is a simple “play an announcement” service, RFC 5552 uses VoiceXML and RFC 6230/RFC 6231/RFC 6505 use SIP/SDP to establish a two-way control channel between the AS and MRFC.
IMS allows any of the three mechanisms to be used, or combinations depending on circumstances.
All three mechanisms are transparent to proxy components, so supported by Clearwater.

History-Info (draft-ietf-sipcore-rfc4244bis - not RFC 4244, which is inaccurate wrt real implementations)¶

Primarily aimed at ASs - need to manipulate History-Info headers when diverting calls. The MMTEL AS built into Sprout already supports this for CDIV.
Also, need to proxy History-Info headers transparently. Clearwater supports this.
However, s9.1 says if the incoming H-I is missing or wrong, the intermediary must add an entry on behalf of the previous entity. Clearwater does not currently do this so if other parts of the network are not compliant, Clearwater will not fill in for them (and should).

OMS Push-to-Talk over Cellular service (RFC 4354, RFC 4964 and RFC 5318)¶

Covers poc-settings event package (RFC 4354), P-Answer-State header (RFC 4964) and P-Refused-URI-List header (RFC 5318)
Only required for OMA push-to-talk over cellular service.
Optional according to TS 24.229.
Transparent to proxies, so supported by Clearwater.

Conference event package (RFC 4575)¶

Defines an event package for various events associated with SIP conferences.
Mandatory for UEs and IMS application servers providing conference services.
Transparent to proxies, so supported by Clearwater.

Event notification resource lists (RFC 4662)¶

Defines an extension to the SUBSCRIBE/NOTIFY event mechanisms that allow an application to subscribe for events from multiple resources with a single request, by referencing a resource list.
In IMS, this is only required for presence events, and is only mandatory for UEs supporting presence or presence servers, otherwise it is optional.
Should be transparent to proxies, so supported by Clearwater.

Multiple-Recipient MESSAGE requests (RFC 5365)¶

Defines a mechanism for MESSAGE requests to be sent to multiple recipients by specifying the list of recipients in the body of the message. A message list server then fans the MESSAGE out to the multiple recipients.
The function is mandatory in an IMS message list server, but not required anywhere else in the network.
Transparent to proxies, so supported by Clearwater.

Creating multi-party conferences (RFC 5366)¶

Allows a SIP UA to establish a multi-party conference by specifying a resource list in the body of the message used to set up the conference.
Mandatory for IMS conference app servers.
Transparent to proxies, so supported by Clearwater.

Referring to multiple resources (RFC 5368)¶

Allows a SIP UA to send a REFER message containing a resource list URI. One use case for this could be to send a single REFER to a conference server to get it to invite a group of people to a conference.
Optional according to TS 24.229, and only applicable to UEs and any application servers that can receive REFER requests.
Transparent to proxies, so supported by Clearwater.

P-Served-User header (RFC 5502)¶

Only applicable on the ISC interface - used to clear up some ambiguities about exactly which user the AS should be providing service for.
Optional according to TS 24.229.
This header is supported by Clearwater and included on requests sent to application servers.

Message body handling (RFC 5621)¶

Defines how multiple message bodies can be encoded in a SIP message.
Relevant in handling of third-party REGISTERs on ISC where XML encoded data from iFC may be passed to AS.

SIP outbound support (RFC 5626)¶

Defines mechanisms for clients behind NATs to connect to a SIP network so SIP requests can be routed to the client through the NAT.
Mandatory according to TS 24.229.
Supported by Clearwater for NAT traversal, except for the Flow-Timer header (which tells the client how often to send keepalives).

Fixes to Record-Route processing (RFC 5658)¶

Fixes some interoperability issues in basic SIP handling of Record-Route headers, particularly in proxies which have multiple IP addresses.
Clearwater used RFC5658 double-record routing in Bono nodes when transitioning between the trusted and untrusted zones on different port numbers.

Fixes for IPv6 addresses in URIs (RFC 5954)¶

Fixes a minor problem in the ABNF definition in RFC 3261 relating to IPv6 addresses, and clarifies URI comparison rules when comparing IPv6 addresses (in what looks like an obvious way).
Mandatory according to TS 24.229.
Supported by Clearwater.

Q.950 codes in Reason header (RFC 6432)¶

Defines how Q.950 codes can be encoded in Reason header.
Mandatory for MGCFs, optional for proxy components in IMS.
Transparent to proxies anyway, so supported by Clearwater.

Geolocation (RFC 4483 and RFC 6442)¶

Framework for passing geo-location information within SIP messages.
According to TS 24.229 only required on an E-CSCF.
Supported by Clearwater as headers will be passed transparently.

Proxy Feature Capabilities (referenced as draft-ietf-sipcore-proxy-feature-12, but now RFC 6809)¶

Defines a mechanism to allow SIP intermediaries (such as registrars, proxies or B2BUAs) to signal feature capabilities when it would not be appropriate to use the feature tags mechanism in the Contact header as per RFC 3841.
Mandatory on P-CSCF according to TS 24.229, but not clear what this actually means as the IMS specs don’t seem to actually define any features to be signalled in these headers.
Clearwater will forward these headers if specified by other nodes in the signaling path, so this is supported.

Alert info URNs (draft-ietf-salud-alert-info-urns-06)¶

Defines family of URNs to be used in Alert-Info header to provide better control over how user is alerted on a UE.
Optional according to TS 24.229.
Transparent to proxies, so supported by Clearwater.

AKA Authentication (RFC 3310)¶

This RFC defines how AKA authentication parameters map into the authentication and authorization headers used for digest authentication.
IMS allows AKA authentication as an alternative to SIP digest, although it is not mandatory.
While Bono doesn’t support AKA, the IMS Core part of Clearwater (Sprout, Vellum and Dime) has support for both AKAv1 and AKAv2.

SIP Instant Messaging (RFC 3428)¶

Defines the use of the SIP MESSAGE method to implement an instant messaging service.
Mandatory in proxy components according to TS 24.229.
Supported in Clearwater.

Registration Events (RFC 3680)¶

Defines an event package supported by SIP registrars to notify other devices of registrations.
Must be supported by IMS core for the ISC interface, and also needed by some UEs.
Supported in Clearwater since sprint 40 “Yojimbo”

PRACK support (RFC 3262)¶

Defines a mechanism for ensuring the reliability of provisional responses when using an unreliable transport. Covers the PRACK method and the Rseq and Rack headers.
Optional according to TS 24.229.
Supported in Clearwater.

Fixes to issues with SIP non-INVITE transactions (RFC 4320)¶

Defines changes to RFC 3261 procedures for handling non-INVITE transactions to avoid some issues - in particular the potential for an O(N^2) storm of 408 responses if a transaction times out.
Mandatory for all SIP nodes according to TS 24.229.
Supported in Clearwater.

User agent capabilities and caller preferences (RFC 3840 and RFC 3841)¶

User agent capabilities encoded as feature tags in Contact headers during registration (RFC 3840) and Accept-Contact, Reject-Contact and Request-Disposition headers encode filtering rules to decide which targets subsequent request should be routed/forked to (RFC 3841).
Used for routing of requests to targets with the appropriate features/capabilities in IMS. Mandatory for proxy components.
Clearwater’s Sprout registrar has full support for storing, matching, filtering and prioritizing bindings based on advertised capabilities and requirements as per these specifications.

AKAv2 (RFC 4169)¶

An updated version of Authentication and Key Agreement, which incorporates the integrity key and cryptographic key into the response calculation.
While Bono doesn’t support AKA, the IMS Core part of Clearwater (Sprout, Vellum and Dime) has support for both AKAv1 and AKAv2.

P-Profile-Key header (RFC 5002)¶

Used solely between I-CSCF and S-CSCF to signal the public service identity key to be used when a requested public service identity matches a wildcard entry in the HSS. Purely an optimization to avoid having to do wildcard matching twice for a single request.
Optional according to TS 24.229
Supported in Clearwater.

Relevant to Clearwater and partially supported¶

GRUUs (RFC 5627, plus RFC 4122, draft-montemurro-gsma-imei-urn-11 and draft-atarius-dispatch-id-meid-urn-10)¶

RFC 5627 defines mechanisms to assign and propagate a Globally-Routable User Agent URI for each client that registers with the SIP network. A GRUU identifies a specific user agent rather than a SIP user, and is routable from anywhere in the internet. GRUUs are intended to be used in scenarios like call transfer where URIs are required for individual user agents to ensure the service operates correctly. Standard Contact headers would seem to do the job in many cases but don’t satisfy the globally routable requirement in all cases, for example where the client is behind certain types of NAT.
Assignment and use of GRUUs is mandatory for S-CSCF and UEs in an IMS network. RFC 4122, draft-montemurro-gsma-imei-urn-11 and draft-atarius-dispatch-id-meid-urn-10 are referenced from the sections of TS 24.229 that discuss exactly how GRUUs should be constructed.
Clearwater supports assigning and routing on public GRUUs as of the Ninja Gaiden release. It does not support temporary GRUUs.
The Blink softphone client can be used to test this, as it provides the +sip.instance parameter needed for GRUU support.

Registration event package for GRUUs (RFC 5628)¶

Defines an extension to the RFC 3680 registration event package to include GRUUs.
Mandatory on S-CSCF and UEs in an IMS network.
Clearwater includes public GRUUs in these event notifications as of the Ninja Gaiden release. It does not support temporary GRUUs.

Alternative URIs (RFC 2806, RFC 2368, RFC 3859, RFC 3860, RFC 3966)¶

Various RFCs defining alternatives to SIP URI - Tel URI (RFC 2806 and RFC 3966), mailto URI (RFC 2368), pres URI (RFC 3859), and im URI (RFC 3860).
IMS allows use of Tel URIs
- as a public user identity associated with a subscription (although a subscription must have at least on public user identity which is a SIP URI)
- as the target URI for a call.
Other URIs can be specified as Request URI for a SIP message.
Clearwater supports SIP and Tel URIs but not mailto, pres or im URIs.

Number portability parameters in Tel URI (RFC 4694)¶

Defines additional parameters in Tel URI for signaling related to number portability.
Used in IMS in both Tel and SIP URIs for carrier subscription scenarios, and in IMS core for other number portability related scenarios.
Optional according to TS 24.229.
The rn and npdi parameters are supported by Clearwater; Clearwater doesn’t currently support the other parameters defined in this RFC.

Relevant to Clearwater but not currently supported¶

These are the RFCs which are relevant to Clearwater and not yet supported.

Dialstring URI parameter (RFC 4967)¶

Defines a user=dialstring parameter used in SIP URIs to indicate that the user portion of the URI is a dial string (as opposed to a number that definitely identifies a phone as in the user=phone case).
IMS allows this encoding from UEs initiating calls, but doesn’t specify any particular processing within the core of the network. The intention is that this can be handled by an application server, or captured by filter criteria.
Clearwater doesn’t currently support this.

P-Early-Media header (RFC 5009)¶

Used to authorize and control early media.
If P-CSCF is not gating media then required function is as simple as
- adding P-Early-Media header with supported value on requests from clients (or modifying header from clients if already in message)
- passing the header through transparently on responses.
If P-CSCF is gating media then function is more complex as P-CSCF has to operate on values in P-Early-Media headers sent to/from UEs.
Mandatory in a P-CSCF according to TS 24.229.
Clearwater doesn’t currently support this.

P-Media-Authorization header (RFC 3313)¶

According to TS 24.229, only required if P-CSCF supporting IMS AKA authentication with IPsec ESP encryption, or SIP digest authentication with TLS encryption.
Not supported, as this is P-CSCF only (and Bono doesn’t support AKA).

Signalling Compression aka SigComp (RFC 3320, RFC 3485, RFC 3486, RFC 4077, RFC 4896, RFC 5049, RFC 5112)¶

RFC 3320 defines basic SigComp (which is not SIP-specific), RFC 3485 defines a static dictionary for use in SigComp compression of SIP and SDP, RFC 3486 defines how to use SigComp with SIP, RFC 4077 defines a mechanism for negative acknowledgements to signal errors in synchronization between the compressor and decompressor, RFC 4896 contains corrections and clarifications to RFC 3320, RFC 5049 contains details and clarifications for SigComp compression of SIP, and RFC 5112 defines a static dictionary for use in SigComp compression of SIP presence bodies.
TS 24.229 says that SigComp is mandatory between UEs and P-CSCF if access network is one of the 3GPP or 802.11 types (specifically it says this is mandatory if the UE sends messages with the P-Access-Network-Info set to one of these values - ie. the UE knows that is the type of access network it is being used on). Compression must use the dictionaries defined in both RFC 3485 and RFC 5112.
Clearwater does not currently support SigComp (although it would be relatively straightforward to implement it).

Reason header (RFC 3326)¶

Already supported in Clearwater for responses, would need to add support for passing on CANCEL requests (but pretty easy).
Optional according to TS 24.229.

Security-Client, Security-Server and Security-Verify headers (RFC 3329)¶

Defines headers that can be used to negotiate authentication mechanisms.
Only required if P-CSCF supporting IMS AKA authentication with IPsec ESP encryption, or SIP digest authentication with TLS encryption.
Not supported, as these headers are always caught by the P-CSCF (and Bono doesn’t support AKA).

SMS over IP (RFC 3862 and RFC 5438)¶

Covers CPIM message format used between UEs and AS implementing SMS-GW function (RFC 3862) and Message Disposition Notifications sent from the SMS-GW to the UE (RFC 5438).
Transported as body in MESSAGE method across IMS core, so transparent to proxy components. Therefore should be supported by Clearwater once we have tested support for MESSAGE methods.

SIP over SCTP (RFC 4168)¶

Defines how SIP can be transported using SCTP (instead of UDP or TCP).
IMS allows SCTP transport within the core of the network, but not between P-CSCF and UEs.
Clearwater does not support SCTP transport (nor does PJSIP). Strictly speaking this is relevant to Clearwater, but it’s not clear whether anyone would use it.

Signalling pre-emption events (RFC 4411)¶

Defines use of the SIP Reason header in BYE messages to signal when a session is being terminated because of a network pre-emption event, for example, if the resources originally acquired for the call were need for a higher priority session.
Optional according to TS 24.229.
Not currently supported by Clearwater.

Resource Priority (RFC 4412)¶

Covers Resource-Priority and Accept-Resource-Priority headers. Intended to allow UEs to signal high priority calls that get preferential treatment by the network (for example, emergency service use).
Not currently supported by Clearwater.
Optional according to TS 24.229.

Service URNs (RFC 5031)¶

Defines a URN namespace to identify services. IMS allows UEs to use such service URNs as target URIs when establishing a call. In particular, it is mandatory for UEs to signal emergency calls using a service URN of the form urn:service:sos possibly with a subtype, and the P-CSCF must be able to handle these requests appropriately, routing to an E-CSCF.
Clearwater currently has no support for service URNs.

Rejecting anonymous requests (RFC 5079)¶

Defines a status code used to reject anonymous requests if required by local policy/configuration.
Optional according to TS 24.229.
Not currently supported by Clearwater.

Subscribing to events on multiple resources (RFC 5367)¶

Allows a SIP node to subscribe to events on multiple resources with a single SUBSCRIBE message by specifying a resource list in the body of the message.
Optional for any IMS node that can be the target of a SUBSCRIBE request.
Not currently supported by Clearwater.

Max-Breadth header (RFC 5393)¶

Intended to plug an amplification vulnerability in SIP forking. Any forking proxy must limit the breadth of forking to breadth specified in this header.
According to TS 24.229 is mandatory on any node that supports forking.
Not currently supported by Clearwater.

Media feature tag for MIME application subtypes (RFC 5688)¶

Defines a media feature tag to be used with the mechanisms in RFC 3840 and RFC 3841 to direct requests to UAs that support a specific MIME application subtype media stream.
According to TS 24.229 support for this feature tag is mandatory on S-CSCFs.
Not currently supported, but support may drop out of implementing RFC 3840/RFC 3841 (depending on the what match criteria the tag requires).

XCAPdiff event package (RFC 5875)¶

Defines an event package allowing applications to get notifications of changes to XCAP documents.
Used by IMS at Ut reference point to allow UEs to control service settings. According to TS 24.229, mandatory for XDMS server, but optional for UEs.
Not supported by Homer.

Correct transaction handling of 2xx responses to INVITE (RFC 6026)¶

A fix to basic SIP transaction model to avoid INVITE retransmissions being incorrectly identified as a new transaction and to plug a security hole around the forwarding of uncorrelated responses through proxies. The change basically adds a new state to the transaction state machine when previously the transaction would have been considered terminated and therefore deleted.
This fix is mandatory according to TS 24.229.
Not supported by Clearwater, and will probably require PJSIP changes.

P-Asserted-Service and P-Preferred-Service headers (RFC 6050)¶

Defines a mechanism to allow a UE to signal the service it would like (although this is not binding on the network) and other components to signal between themselves the service being provided. The UE may optionally include a P-Preferred-Service header on any request specifying the service it wishes to use. The S-CSCF is responsible for checking that the service requested in P-Preferred-Service is (a) supported for the subscriber and (b) consistent with the actual request. If the request is allowed, the S-CSCF replaces the P-Preferred-Service with a P-Asserted-Service header. If either check fails, the S-CSCF may reject the request or it may allow it but ignore the P-Preferred-Service header. If the UE does not specify a P-Preferred-Service header (or the specified one was not valid) the S-CSCF should work out the requested service by analysing the request parameters, and add a P-Asserted-Service header encoding the result.
In IMS networks, header should contain an IMS Communication Service Identifier (ICSI) - defined values are documented at http://www.3gpp.com/Uniform-Resource-Name-URN-list.html - examples include MMTEL (3gpp-service.ims.icsi.mmtel), IPTV (3gpp-service.ims.icsi.iptv), Remote Access (3gpp-service.ims.icsi.ra), and Converged IP Messaging (3gpp-service.ims.icsi.oma.cpm.* depending on exact service being requested/provided).
Mandatory function according to TS 24.229.
Not currently supported by Clearwater.

SIP INFO messages (RFC 6086)¶

Framework for exchanging application specification information within a SIP dialog context.
Not currently supported by Clearwater.
Optional according to TS 24.229.

Indication of support for keepalives (RFC 6223)¶

Adds a parameter to Via headers to allow nodes to agree the type of keepalives to be used to keep NAT pinholes open.
Mandatory for UEs and P-CSCFs, optional elsewhere.
Not currently supported by Clearwater and would require PJSIP changes.

Response code for indication of terminated dialog (RFC 6228)¶

Defines a new status code to indicate the termination of an early dialog (ie. a dialog created by a provisional response) prior to sending a final response.
According to TS 24.229 this parameter is mandatory for all UA components than can send or receive INVITEs, and mandatory for S-CSCF because it has implications on forking proxies.
This is not currently supported by Clearwater.

P-Private-Network-Indication (referenced as draft-vanelburg-sipping-private-network-indication-02)¶

Mechanisms for transport of private network information across an IMS core.
Optional according to TS 24.229.
Not currently supported by Clearwater.

Session-ID header (referenced as draft-kaplan-dispatch-session-id-00)¶

Defines an end-to-end globally unique session identifier that is preserved even for sessions that traverse B2BUAs).
Optional according to TS 24.229.
Not currently supported by Clearwater.

Interworking with ISDN (draft-ietf-cuss-sip-uui-06 and draft-ietf-cuss-sip-uui-isdn-04)¶

Defines mechanisms/encodings for interworking ISDN with SIP.
Optional according to TS 24.229.
Not currently supported by Clearwater.

SDP/Media RFCs¶

TS 24.229 references a number of specifications which relate to media function - either SDP negotiation or media transport or both. Clearwater currently passes SDP transparently and does not get involved in media flows. Unless we change this position, Clearwater can either be considered to support the RFC (because it supports passing SDP with the relevant contents) or that the RFC is not applicable to Clearwater.

The following is a brief explanation of each RFC, and its relevance to IMS.

SDP (RFC 4566) - defines basic SDP protocol.
Offer/Answer model for SDP media negotiation (RFC 3264) - defines how SDP is used to negotiate media.
Default RTP/AV profile (RFC 3551) - defines default mappings from audio and video encodings to RTP payload types.
Media Resource Reservation (RFC 3312 and RFC 4032) - defines additional SDP parameters to signal media resource reservation between two SIP UAs. TS 24.229 requires UEs, MGCFs and ASs to use these mechanisms, and that P-CSCF should monitor the flows if it is performing IMS-ALG or media gating functions.
Mapping of media streams to resource reservation (RFC 3524 and RFC 3388) - define how multiple media streams can be grouped in SDP and mapped to a single resource reservation. IMS requires UEs to use these encodings when doing resource reservations.
Signaling bandwidth required for RTCP (RFC 3556) - by default RTCP is assumed to consume 5% of session bandwidth, but this is not accurate for some encodings, so this RFC defines explicit signaling of RTCP bandwidth in SDP. This function is optional according to TS 24.229.
TCP media transport (RFC 3556 and RFC 6544) - defines how support for TCP media transport is encoded in SDP for basic SDP exchanges and for ICE exchanges. According to TS 24.229, media over TCP is optional in most of an IMS network, but mandatory in an IBCF implementing IMS-ALG function.
ICE (RFC 5245) - defines ICE media negotiation used to establish efficient media paths through NATs. According to TS 24.229 support for ICE is optional in most of the IMS network, but mandatory on an IBCF implementing IMS-ALG function.
STUN (RFC 5389) - defines a protocol used to allow UAs to obtain their server reflexive address for use in ICE.
TURN (RFC 5766) - defines extensions to STUN used to relay media sessions via a TURN server to traverse NATs when STUN-only techniques don’t work.
Indicating support for ICE in SIP (RFC 5768) - defines a media feature tag used to signal support for ICE.
SDP for binary floor control protocol (RFC 4583) - defines SDP extensions for establishing conferencing binary floor control protocol streams. Optional according to TS 24.229.
Real-time RTCP feedback (RFC 4585 and RFC 5104) - defines extensions to RTCP to provide extended real-time feedback on network conditions. Mandatory for most IMS components handling media (MRFs, IBCFs, MGCFs), but optional for UEs.
SDP capability negotiation (RFC 5939) - defines extensions to SDP to allow for signaling and negotiation of media capabilities (such as alternate transports - SRTP). Mandatory for most IMS components handling media (MRFs, IBCFs, MGCFs), but optional for UEs.
SDP transport independent bandwidth signaling (RFC 3890) - defines extensions to SDP to signal codec-only (ie. independent of transport) bandwidth requirements for a stream. Optional for IMS components handling media.
Secure RTP (RFC 3711, RFC 4567, RFC 4568, RFC 6043) - defines transport of media over a secure variant of RTP, supporting encryption (to prevent eavesdropping) and integrity protecting (to protect against tampering). Keys are either exchanged in SDP negotiation (specified in RFC 4567 and RFC 4568) or distributed via a separate key management service - termed MIKEY-TICKEY (specified in RFC 6043).
Transcoder invocation using 3PCC (RFC 4117) - defines how a transcoding service can be inserted into the media path when required using third-party call control flows. According to TS 24.229 this is only applicable to app servers and MRFC, and even then is optional.
MSRP (RFC 4975) - defines a protocol for session-based transmission of a sequence of instant messages. Only applicable to UEs, ASs and MRFCs and optional.
SDP for file transfer (RFC 5547) - defines SDP extensions to support simple file transfers between two IMS nodes. Optional.
Explicit congestion notifications for RTP over UDP (RFC 6679) - defines RTCP extensions for reporting urgent congestion conditions and reporting congestion summaries. Optional.
Setting up audio streams over circuit switched bearers (referenced as draft-ietf-mmusic-sdp-cs-00) - defines SDP extensions for negotiating audio streams over a circuit switched network. Mandatory for ICS capable UEs and SCC-AS, otherwise optional.
Media capabilities negotiation in SDP (referenced as draft-ietf-mmusic-sdp-media-capabilities-08) - defines SDP extensions for signaling media capabilities such as encodings and formats. Mandatory for ICS capable UEs and SCC-AS, otherwise optional.
Miscellaneous capabilities negotiation in SDP (referenced as draft-ietf-mmusic-sdp-miscellaneous-caps-00) - defines SDP extensions for signaling some miscellaneous capabilities. Mandatory for ICS capable UEs and SCC-AS, otherwise optional.

Not Relevant to Clearwater¶

Locating P-CSCF using DHCP (RFC 3319 and RFC 3361)¶

These RFCs describe a mechanism for locating a SIP proxy server using DHCP. (RFC 3319 defines the mechanism for IPv6/DHCPv6, and RFC 3361 is the IPv4 equivalent - not sure why they happened that way round!).
The IMS specifications allows this as one option for a UE to locate a P-CSCF, although there are other options such as manual configuration of a domain name or obtaining it from some access-network specific mechanism.
This is irrelevant to Clearwater - there would be no point in Clearwater providing a DHCP server with this function as there will be existing mechanisms used by clients to obtain their own IP addresses. A service provider might enhance their own DHCP servers to support this function if required.

Proxy-to-proxy SIP extensions for PacketCable DCS (RFC 3603)¶

Only relevance to IMS is that it defines a billing correlation parameter (bcid) which is passed in the P-Charging-Vector header from DOCSIS access networks.

Geolocation (RFC 4119 and RFC 6442)¶

Frameworks for passing geo-location information within SIP messages - RFC 4119 encodes geo-location in a message body, RFC 6442 encodes a URI reference where the UEs location can be found.
According to TS 24.229 only required on an E-CSCF.

P-User-Database header (RFC 4457)¶

Used when an IMS core has multiple HSSs and an SLF - allows I-CSCF to signal to S-CSCF which HSS to use to avoid multiple SLF look-ups.
Optional according to TS 24.229.
Not applicable to Clearwater given its stateless architecture.

URIs for Voicemail and IVR applications (RFC 4458)¶

Defines conventions for service URIs for redirection services such as voicemail and IVR.
Optional according to TS 24.229.

Emergency call requirements and terminology (RFC 5012)¶

Referenced to define some terminology used in IMS architecture for handling emergency calls.

Answering Modes (RFC 5373)¶

Defines a mechanism for a caller to control the answer mode at the target of the call. Use cases can include invoking some kind of auto-answer loopback. Covers the Answer-Mode and Priv-Answer-Mode headers.
In general is transparent to proxies (provided proxies pass headers through), but the RFC recommends the mechanism is not used in environments that support parallel forking.
Optional according to TS 24.229 - and arguably not a good idea because of bad interactions with forking.