RFC 3087: The Voicemail URI Was Not Authentication

Summary

RFC 3087 let a SIP client or proxy communicate an application's starting context by choosing a distinctive Request-URI: deposit here, use this greeting, retrieve this mailbox, or ask for a PIN.
The URI selected a locally provisioned behavior. It did not authenticate the caller, prove why a call was forwarded, authorize mailbox access, or show that a message was stored or heard.

The call arrived, but its old clues did not

A traditional voicemail system could look at a called number, a calling number and a forwarding reason. From those signals it might choose the busy greeting, the no-answer greeting, a particular mailbox, or a retrieval menu for a subscriber calling from their own desk. The convenience depended on a chain of assumptions about what each number and switch event meant.

SIP loosened that chain. A call could be redirected by several proxies. Some of the old call-state information might be absent; some might be unreliable. A stable To field could continue to name the logical person first called even while the request travelled toward a different service. In RFC 3087's compact example, A called B, B forwarded to C, and C forwarded to C's voicemail. A voicemail application that treated To: B as the mailbox selector would open the wrong store.

RFC 3087, published as an Informational memo in April 2001, proposed no new SIP method or header. It used an existing distinction. The To field represented the logical recipient, while a proxy was allowed to rewrite the Request-URI to the current user or service target. If the target could be a service identity, the target could also select the service's initial state.

That sounds small because the mechanism was already present. Its consequence was architectural: context became an explicit routing result rather than an application guess made from historical debris.

One application could expose many doors

The memo gave a voicemail system a set of separately provisioned SIP identities. One URI might mean deposit into a subscriber's mailbox with the ordinary greeting. Another could select a busy greeting or a special greeting. Retrieval could have one entry for a request already authenticated at the SIP layer and another that opened an in-band PIN prompt. Generic entries could ask the caller which mailbox to use.

A find-me proxy could select among those doors. If all contacts expired without an answer, it could route to the normal deposit identity. If a contact returned busy everywhere, it could choose the busy-announcement identity. A do-not-disturb setting could lead to still another application entry. The voicemail service did not have to reconstruct that upstream decision from To, From and switch folklore; it received a current target that already named the intended behavior.

Yet the visible spelling of the URI was not a protocol language. RFC 3087 warned applications not to impose semantic rules on mnemonic strings. An operator might provision deposit, a number, a user name with a parameter, or an arbitrary valid SIP URI. The application had to map the configured identity to behavior. The owner of the system controlled that dictionary.

This is an important evidence limit. Seeing busy in a captured URI can make a trace readable, but the word does not prove a standardized busy condition. It proves only that this string reached this hop. To know its meaning, an investigator needs the provisioning record and the rewrite decision that produced it.

Routing context and admission were different gates

The memo's retrieval cases make the separation explicit. A voicemail service could accept a mailbox-specific retrieval URI from a trusted source whose secure relationship allowed it to delegate authentication. It could honor a request after SIP authentication. If authentication failed, or if the source offered none, the service or protecting proxy could rewrite the request toward an entry that prompted for a PIN.

Thus sip:subscriber-retrieve@... could select the retrieval workflow without granting the retrieval. The Request-URI said which door the request had reached. Trust, SIP credentials or the PIN still decided whether the caller could pass through it.

The distinction mattered even in apparently familiar cases. A gateway might recognize a PSTN calling number and map the call to a subscriber-specific route, but the recognition was an assumption trusted by that provider. It was not cryptographic proof of the person speaking. RFC 3087's detailed flows assumed a protecting proxy and a trust relationship between that proxy and the voicemail system. The final security section added no new protection; it referred the reader to SIP's own security considerations.

A packet trace can therefore support a chain of bounded statements: the proxy received an INVITE; it selected a particular service URI; the application accepted that target; an authentication branch ran; RTP was established. None alone proves that the human caller owned the mailbox, that the stated forwarding reason was historically correct, that the PIN remained secret, that a recording was committed to storage, or that anyone later heard it.

A local convention was not yet an interoperability vocabulary

RFC 3261 later replaced the original SIP specification while preserving the relevant mechanism: the Request-URI names the addressed user or service, and proxy target processing replaces it as a request is routed. Later History-Info specifications gave SIP a way to carry retargeting history. Those developments help explain the layers, but they do not prove that any RFC 3087 installation used them.

RFC 4458 is more revealing. In 2006 it defined target and cause URI parameters for voicemail and interactive voice response. Its motivation was that vendors could make local mappings configurable, but configuration alone was unrealistic for interoperability among call control, gateways and unified messaging systems. RFC 3087 had shown how a URI could be the control surface; RFC 4458 supplied a common vocabulary for two pieces of that control.

The later convention does not make the earlier one a failure. It exposes the difference between two achievements. A system can cleanly separate routing context from a stable logical identity inside one administrative domain. Different systems still need shared syntax and semantics before a mailbox and forwarding cause travel reliably across a vendor boundary.

RFC 3087's durable lesson lies in this evidence chain. The original call target, the current Request-URI, the proxy's reason for rewriting, the local URI-to-behavior map, the authentication result, the selected menu, the media session and the stored message are related records. They are not interchangeable. Putting context into the route reduced guessing. It did not turn routing into identity.

The URI Chose the Voicemail Menu. It Did Not Authenticate the Caller: RFC 3087

Why it matters

Summary

The call arrived, but its old clues did not

One application could expose many doors

Routing context and admission were different gates

A local convention was not yet an interoperability vocabulary

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing