Outgoing initial request

Description

An Outgoing initial request is defined in 3GPP specifications as all requests intended to initiate either a dialog or a standalone transaction received from the served user. In the context of the IP Multimedia Subsystem (IMS), this concept is fundamental to understanding how the network processes requests that originate from a user and are directed toward another party. The term appears primarily in the supplementary service specifications (24.407, 24.408, 24.508, 24.607, 24.608), which cover services such as Communication Diversion, Communication Barring, Communication Waiting, and Explicit Communication Transfer.

In SIP (Session Initiation Protocol) terminology, an initial request is one that is not a response to a previously received request and that does not contain a To tag, meaning it is not part of an existing dialog. Such requests include INVITE, MESSAGE, SUBSCRIBE, and other methods that can either establish a dialog (as INVITE does) or operate as a standalone transaction (as MESSAGE or OPTIONS might). The qualifier 'outgoing' indicates the direction relative to the served user — the request is being sent by the served user rather than received by them.

The concept is critical for supplementary service logic because many IMS services need to distinguish between requests that the served user originates versus those they receive. For example, Communication Barring (CB) services may apply different rules to outgoing versus incoming communications. Similarly, Communication Diversion (CDIV) services need to know whether a request is outgoing from the served user to determine whether diversion rules should be evaluated.

The specifications use this term to define the scope of service interaction. When a supplementary service is invoked, the application server (AS) must determine whether the triggering request qualifies as an outgoing initial request from the served user. This determination affects which service logic is applied and how the request is subsequently routed or processed.

From an architectural perspective, the Outgoing initial request is processed at the Serving-CSCF (S-CSCF), which evaluates initial Filter Criteria (iFC) to determine which application servers should be invoked. The AS then applies service-specific logic. If the request is identified as an outgoing initial request from a served user who has supplementary services provisioned, the relevant service logic is executed.

The term has remained stable across all releases from Rel-7 through Rel-19, indicating that the fundamental definition of what constitutes an outgoing initial request has not changed. This stability reflects the maturity of the IMS architecture and the SIP protocol foundations upon which it is built. The definition's consistency across nearly two decades of specifications demonstrates that the concept is well-understood and unambiguous within the 3GPP framework.

Purpose & Motivation

The concept of an Outgoing initial request exists to provide a precise, unambiguous definition of which SIP requests should trigger supplementary service logic on the originating side. In IMS networks, supplementary services such as Communication Barring, Communication Diversion, and Communication Waiting must be able to determine whether a given request is one that the served user is originating. Without a clear definition, different implementations might interpret the scope of service applicability differently, leading to interoperability problems.

The term addresses the fundamental need to distinguish between originating and terminating requests in a multi-service IMS environment. When a user originates a communication, the network must evaluate whether any originating supplementary services apply — for example, whether the user has barred outgoing calls to certain destinations or whether outgoing communication diversion rules should be applied. The Outgoing initial request definition provides the precise scope for these evaluations.

Historically, as IMS supplementary services were being standardized in Rel-7, there was a need for consistent terminology across multiple specifications. The definition was crafted to cover both dialog-initiating requests (such as INVITE) and standalone transaction requests (such as MESSAGE), ensuring that the term's applicability was not limited to session-based communications. This breadth was important as IMS evolved to support messaging and other non-session services alongside traditional voice and video sessions.