Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.228  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…   AC.10… 
S Business Trunking  S.1 General  S.2 IP-PBXs using static mode Business Trunking  S.2.1 High level architecture  S.2.2 High level Flows  S.2.2.1 General  S.2.2.2 Originating procedures  S.2.2.2.1 Originating procedures using the S-CSCF  S.2.2.2.2 Originating procedures using the Transit Function  S.2.2.3 Terminating Procedures  S.2.2.3.1 Terminating procedures using the S-CSCF  S.2.2.3.2 Terminating procedures using the Transit Function 
...

 

S (Normative)  Business Trunking |R12|  p. 302

S.1  General  p. 302

This annex describes the IMS architecture and procedures for support of IP-PBX business trunking.
Two different modes of operation are supported
  • Registration mode, or
  • Static mode.
In both modes, the IP-PBX can be provisioned as a subscriber in the HSS.
In registration mode, the IP-PBX registers to and receives service from the IMS network as specified in TS 24.525.
The architecture and procedures for an IP- PBX using static mode is described in clause S.2.
Up

S.2  IP-PBXs using static mode Business Trunking  p. 302

S.2.1  High level architecture  p. 302

The support for business trunking in static mode is provided by either an IBCF or a P-CSCF.
The architecture for support of IP-PBX in static mode of operation is shown in Figure S.2-1.
Reproduction of 3GPP TS 23.228, Fig. S.2-1: High level Static mode business trunking Architecture
Figure S.2-1: High level Static mode business trunking Architecture
Up
The IP-PBX identity assertion and the routing of terminating sessions are performed by Application Server(s), which may or may not also host a business trunking application. The architecture for support of IP-PBX in static mode of operation shown in Figure S.2-1 allows for two different deployment alternatives.
  • The Application Server(s) hosting these functionalities are invoked by the S-CSCF based on Initial Filter Criteria contained in the unregister part of the IP-PBX's subscriber profile, retrieved from the HSS.
  • As according to clause 4.15 and TS 24.525, this deployment relies on the Transit function with Application Server(s) hosting these functionalities are invoked by the Transit Function based on transit invocation criteria, which need to be provisioned in the Transit Function.
In both cases, the AS performing the routing of terminating sessions needs to be the last AS invoked for terminating sessions.
Both deployment options can simultaneously be used in in an IMS Network, although it requires that the enterprise user identities allocated in the different deployments are not overlapping.
Up

S.2.2  High level Flows  p. 303

S.2.2.1  General  p. 303

Before any originating or terminating procedures can take place between the IP-PBX and the P-CSCF or between the IP-PBX and the IBCF of the IMS network, security and authentication between the IP-PBX and IMS is done using the TLS procedures according to TS 33.310, using certificates. The certificates are provided by a trusted root. The P-CSCF or the IBCF is provisioned with its own certificate, and will receive the IP-PBX certificate during the TLS handshake.
In configurations where there is a NAT between the IP-PBX and the IMS, the TLS connection needs to be initiated and maintained by the IP-PBX.
If the network between the PBX and the IBCF complies with the peering based interconnect procedures according to TS 24.525, the IBCF may deploy the Gq' interface. The Gq' interface and its interactions are not depicted in these flows.
Up

S.2.2.2  Originating procedures  p. 303

S.2.2.2.1  Originating procedures using the S-CSCF  p. 303
This clause depicts originating procedures for IP-PBXs using static mode business trunking when the IP-PBX is provisioned as a subscriber in HSS and served via the S-CSCF.
Reproduction of 3GPP TS 23.228, Fig. S.2.2.2-1: Originating procedures for IP-PBXs using static mode business trunking and served by the S-CSCF.
Figure S.2.2.2-1: Originating procedures for IP-PBXs using static mode business trunking and served by the S-CSCF.
Up
The following steps are performed:
Step 1.
An enterprise user within the IP-PBX tries to establish a call. The IP-PBX sends an INVITE towards IMS via the P-CSCF or via the IBCF (contact point for the IP-PBX). If no security association exists between the P-CSCF/IBCF and the IP-PBX, TLS will be initiated as a result of trying to send the INVITE. Once the TLS session is setup (using the certificates), the INVITE will be sent over the secure connection. The INVITE is assumed to include a calling party identity.
Step 2.
The P-CSCF/IBCF may apply general screening rules to the request and adds a P-Served-User-Identity to the INVITE with the identity of the PBX (SIP URI identifying the domain of the PBX retrieved from the certificate). Additionally, the P-CSCF/IBCF adds the orig parameter to the INVITE to indicate that this is an origination request. The P-CSCF/IBCF forwards the INVITE to the I-CSCF.
Step 3.
The I-CSCF performs the normal (originating request) user location request towards HSS to find an S-CSCF to serve the IP-PBX. If there is no subscription in the HSS, the I-CSCF forwards the request to a Transit Function (and routing may continue as described in step 4 of clause S.2.2.2.2); otherwise, the following steps are performed.
Step 4.
The I-CSCF forwards the request to the S-CSCF.
Step 5.
When the S-CSCF does not have the IP-PBX's subscriber profile, the S-CSCF contacts HSS to download the subscriber information for the unregistered IP-PBX.
Step 6.
The S-CSCF performs normal (unregistered) originating service invocation for the incoming request.
Step 7.
The S-CSCF forwards the request to the AS hosting the IP-PBX identity assertion. Based on the P-Served-User-Identity, this AS identifies the IP-PBX and inserts a P-Asserted-Identity identifying the enterprise user. Other Application Servers may be triggered based on iFC and may, based on the P-Asserted-Identity, perform any enterprise specific actions if required.
Step 8.
Each of the triggered ASs may optionally query HSS for any subscriber information if required using the Sh interface.
Step 9.
The INVITE is forwarded to S-CSCF for further onward routing towards the remote side.
Step 10.
The S-CSCF performs onward routing towards the remote side.
Step 11.
The session setup is completed.
Up
S.2.2.2.2  Originating procedures using the Transit Function  p. 304
This clause depicts the originating procedures for IP-PBXs using static mode business trunking as described in TS 24.525 when the IP-PBX is not provisioned as a subscriber in HSS and served via the Transit Function.
Reproduction of 3GPP TS 23.228, Fig. S.2-2: Originating procedures for IP-PBXs using static mode business trunking and served by the Transit Function
Figure S.2-2: Originating procedures for IP-PBXs using static mode business trunking and served by the Transit Function
Up
The following steps are performed:
Step 1.
An enterprise user within the IP-PBX tries to establish a call. The IP-PBX sends an INVITE towards IMS via the IBCF (contact point for the IP-PBX). If no security association exists between the IBCF and IP-PBX, TLS will be initiated as a result of trying to send the INVITE. Once the TLS session is setup (using the certificates), the INVITE will be sent over the secure connection. The INVITE is assumed to include a calling party identity.
Step 2a.
The IBCF may apply general screening rules to the request, and adds a P-Served-User-Identity to the INVITE with the identity of the IP-PBX (SIP URI identifying the domain of the IP-PBX retrieved from the certificate). Additionally, the IBCF adds the orig parameter to the INVITE to indicate that this is an origination request. The IBCF sends the INVITE to the I-CSCF).
Step 2b.
The IBCF performs the same actions as in step 2a. but sends the INVITE directly to the Transit Function instead of the I-CSCF. (The next step is step 5).
Step 3.
The I-CSCF performs the normal (originating request) user location request towards HSS to find the served user, but as it is not provisioned in HSS, "user not found" is returned.
Step 4.
The I-CSCF sends the INVITE to the Transit Function.
Step 5.
The Transit Function is configured with a set of Transit invocation criteria that are triggered to find a correct AS to route to. As this is an origination case (as indicated by the orig parameter), the P-Served-User-Identity is used to identify the IP-PBX.
Step 6.
The Transit Function forwards the request to the AS hosting the IP-PBX identity assertion. Based on the P-Served-User-Identity, this AS identifies the IP-PBX, verifies that this IP-PBX is a valid user and inserts a P-Asserted-Identity identifying the enterprise user. Other ASs may be triggered based on iFC and may, based on the P-Asserted-Identity, apply any enterprise specific actions if required.
Step 7.
The INVITE is forwarded for further onward routing towards the remote side.
Step 8.
Transit Function performs onward routing towards the remote side.
Step 9.
The session setup is completed.
Up

S.2.2.3  Terminating Procedures  p. 305

S.2.2.3.1  Terminating procedures using the S-CSCF  p. 305
This clause depicts terminating procedures for IP-PBXs using static mode business trunking when the IP-PBX is provisioned as a subscriber in HSS and served via the S-CSCF.
Reproduction of 3GPP TS 23.228, Fig. S.2-3: Terminating procedures for IP-PBXs using static mode business trunking and served by the S-CSCF
Figure S.2-3: Terminating procedures for IP-PBXs using static mode business trunking and served by the S-CSCF
Up
The following steps are performed:
Step 1.
An INVITE is sent from the remote side towards the I-CSCF with a Request-URI which belongs to a particular enterprise user of a served IP-PBX.
Step 2.
The I-CSCF performs the normal user location request towards HSS to find an S-CSCF to serve the IP-PBX.
Step 3.
The I-CSCF forwards the request to the S-CSCF.
Step 4.
When the S-CSCF does not have the IP-PBX's subscriber profile, the S-CSCF contacts HSS to download the subscriber information for the unregistered IP-PBX.
Step 5.
The S-CSCF performs normal (unregistered) terminating service invocation for the incoming request.
Step 6.
The S-CSCF forwards the request to the ASs to be triggered per iFC. Each of these ASs may identify the IP-PBX the enterprise user belongs to and perform any enterprise specific actions if required.
Step 7.
Each of the triggered ASs may optionally query HSS for any subscriber information if required using the Sh interface.
Step 8.
The IP-PBX routing functionality (hosted by the last AS in the iFC chain) identifies the particular IP-PBX the enterprise user belongs to, and also the P-CSCF(s) or the IBCF(s) serving the IP-PBX, and forwards the INVITE toward the IP-PBX (by creating a route to the IP-PBX, adding the S-CSCF, the P-CSCF/IBCF, and the IP-PBX in the Route header fields).
Step 9.
The INVITE is forwarded using the route information to the P-CSCF or the IBCF.
Step 10.
The P-CSCF/IBCF will forward the INVITE to the IP-PBX using the route information provided by the IP-PBX routing functionality. If no security association exist between the P-CSCF/IBCF and the IP-PBX (and TLS is used), TLS will be initiated as a result of trying to send the INVITE. Once the TLS session is setup (using the certificates) the INVITE will be sent over the secure connection.
Step 11.
The session setup is completed.
Up
S.2.2.3.2  Terminating procedures using the Transit Function  p. 306
This clause depicts the terminating procedures for IP-PBXs using static mode business trunking as described in TS 24.525 when the IP-PBX is not provisioned as a subscriber in HSS and served via the Transit Function.
Reproduction of 3GPP TS 23.228, Fig. S.2-4: Terminating procedures for IP-PBXs using static mode business trunking and served by the Transit Function
Figure S.2-4: Terminating procedures for IP-PBXs using static mode business trunking and served by the Transit Function
Up
The following steps are performed:
Step 1.
An INVITE is sent from the remote side via an incoming IBCF towards the Transit Function with a Request-URI targeting an enterprise user allocated to a particular IP-PBX.
Step 2.
The Transit Function will based on the Request-URI determine that the served user is belonging to an IP-PBX and corresponding transit invocation criteria that are used to identify the ASs to be triggered, including the AS hosting the IP-PBX routing functionality, which is the last AS to be triggered.
Step 3.
The Transit Function forwards the request to the required ASs. Each of these ASs may identify the IP-PBX the enterprise user belongs to and perform any enterprise specific actions if required.
Step 4.
The IP-PBX routing functionality (hosted by the last AS in the chain) identifies the particular IP-PBX the enterprise user belongs to, and optionally also the IBCF(s) serving the IP-PBX, and forwards the INVITE toward the IP-PBX by creating a route to the IP-PBX, adding the Transit Function, the IBCF, and the IP-PBX in the Route header fields.
Step 5.
The INVITE is forwarded using the route information to the IBCF.
Step 6.
The IBCF will forward the INVITE to the IP-PBX using the route information provided by the AS. If no security association exist between the IBCF and the IP-PBX (and TLS is used), TLS will be initiated as a result of trying to send the INVITE. Once the TLS session is setup (using the certificates) the INVITE will be sent over the secure connection.
Step 7.
The session setup is completed.
Up

Up   Top   ToC