URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (26)
A private extension mechanism using @provider syntax is provided specifically to facilitate PBX-to-SIP migrations without requiring IANA coordination. Because existing PBX products use diverse proprietary conventions, the scheme must accommodate uncoordinated national and vendor variations while still enabling interoperation through the truncation fallback rules.
The hierarchical URN structure is designed so that removing the final <alert-ind-part> always produces a less-specific but still meaningful URN. This enables graceful degradation: a receiver that does not recognize a full URN can truncate it until it reaches a recognizable parent, preserving partial intent rather than silently ignoring the entire indication.
URNs are chosen over URLs of downloadable audio files to avoid download latency, formatting/compatibility issues, security risks of rendering unexpected content, and to allow local storage in any format. The URN specifies a rendering 'by name' rather than 'by value', enabling local policy decisions and accessibility adaptations.
A UA MUST produce a reasonable rendering when the Alert-Info header field contains a mix of URI schemes (e.g., an HTTP audio URL and an 'alert' URN). It must act on the URIs it understands per local policy and ignore the others; the proxy example in Section 14 shows both an HTTP URI and a URN coexisting in the same header field.
Backward compatibility with existing SIP devices is expected because devices that do not understand an 'alert' URN should ignore it, and multiple Alert-Info values were syntactically permitted by RFC 3261 before this document even though they were rarely used in practice.
A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response when it needs to modify information about the call or provided services.
'alert' URN labels MUST comply with the syntax for Non-Reserved LDH labels (RFC 5890). Registered URNs and components thereof MUST be transmitted as registered (including case), while comparison is case-insensitive.
Extensions (standard or private) MUST conform to three principles: a new <alert-category> must be independent of all existing ones; a multi-part new <alert-identifier> must be a semantic refinement of its parent; and sibling <alert-identifier>s must have no semantic overlap.
Future interpreters of 'alert' URNs MUST operate correctly per Section 11.1 when given URNs containing A-labels (internationalized <alert-label>s), even though the current specification restricts <alert-label>s to ordinary ASCII LDH labels.
If subsequent provisional responses within the same dialog contain different Alert-Info header field values, the UA SHOULD render, at any time, the last received Alert-Info header field value. Values from different provisional responses are treated independently.
Private extensions MUST NOT duplicate any standard URN or any private extension that the defining organization is aware of; in either case, the organization MUST use the existing URN. Private extensions must also respect the independence and subset principles of Section 10.1.
The Alert-Info header field, previously permitted only in 180 (Ringing) responses, is now additionally allowed in any non-100 provisional response to INVITE. This enables signaling of tones for situations such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued).
Upon receiving an Alert-Info header field, the UA's processing MUST conform to the priority rules in Section 11. The UA MUST produce a rendering based on URIs it can understand; unless the message is immediately rejected, it SHOULD provide some alert unless instructed otherwise.
When a UA cannot render a URN because it is unrecognized or precluded by preceding URNs, it MUST repeatedly remove the final <alert-ind-part> until the resulting URN is renderable or has no <alert-ind-part> remaining, in which case the URN is ignored. Earlier URNs have precedence over later ones.
When selecting from equally effective signals after processing all received URNs, the least-specific signal SHOULD be chosen; a more-specific signal may be chosen only if the choice is based on information derived from the containing SIP message (e.g., a 'Priority: urgent' header field).
Private-extension URNs use a <private-name> syntax of the form <alert-label>@<provider>, where <provider> is registered with IANA. A private-name may appear as either an <alert-category> or an <alert-ind-part>, and all subsequent <alert-label>s until the next <private-name> are owned by that organization.
Six <alert-category> values are defined: 'service' (telephony service type), 'source' (classification of the other call party), 'priority' (call priority), 'duration' (alerting signal duration), 'delay' (presentation delay), and 'locale' (country-specific alerting conventions).
The 'alert' URN namespace uses a hierarchical Namespace Specific String of the form urn:alert:<alert-category>:<alert-indication>, where <alert-indication> is composed of one or more colon-separated <alert-ind-part>s. The ABNF constrains components to Non-Reserved LDH labels per RFC 5890.
The 'priority' category carries normal (default), low, and high indications; 'duration' carries normal (default), short, and long; 'delay' carries none (default) and yes; 'locale' carries default and country:<ISO 3166-1 code> patterns.
The 'service' category carries indications: normal (default), call-waiting, forward, recall:callback, recall:hold, and recall:transfer. These cover common PBX and public telephony services without binding to a particular audio rendering.
The 'source' category carries indications: unclassified (default), internal, external, friend, and family. These are typically inserted by a proxy acting on behalf of the recipient UA to convey the origin of the call.
A new 'Alert URN Identifiers' registry is created, managed under the 'Specification Required' policy (RFC 5226). It records standardized <alert-category> and <alert-identifier> values with reference and description. A new URN MUST NOT be registered if it equals an already-registered URN under case-insensitive comparison.
A new 'Alert URN Providers' registry is created, managed under the 'First Come First Served' policy (RFC 5226), recording <provider> values used to construct <private-name>s. Each entry contains the provider value, registrant name, and contact URI. Private extension URNs themselves are not registered with IANA.
Authorization for providing alert indications SHALL NOT assume any limitation on potential recipients without obtaining specific information about the SIP transaction. A proxy SHOULD remove indications from untrusted sources that may be deceptive or that contain information to be suppressed for privacy reasons.
Providing specific alert indications (e.g., call-waiting or call-forwarding) can reveal the dialog state of the source UA or services initiated at its end. Such provision SHALL always require authorization on behalf of the user of the source UA, typically through configured policy.
The 'alert' URN is an identifier and does not by itself raise security issues, since it avoids the need to download or dereference a resource. This eliminates risks associated with fetching and rendering untrusted audio content that exist with HTTP URL-based Alert-Info references.