Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  16.6.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.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.8…   5.11…   5.11.3…   5.11.4…   5.11.5…   5.11.6…   5.12…   5.16…   5.19   5.20…   A…   E…   E.2.2…   G…   G.5…   H…   J…   L…   N…   Q…   Q.2.5…   R…   S…   U…   U.2…   V…   Y…   Z…   AA…   AA.3…

 

N (Normative)  Aspects for use of Common IMS in Fixed xDSL, Fiber and Ethernet based systems |R8|Word‑p. 269

N.1  Origination procedures

N.1.1  (FO#1) Fixed xDSL origination, home

This origination procedure applies to users located in their home service area. As in clause 5.6.2, the UE is located in the home network, but is using an xDSL IP-CAN to access the IM CN Subsystem.
(not reproduced yet)
Figure N.1.1: Fixed xDSL originating - home (example flow)
Up
Procedure F0#1 is as follows:
Step 1.
UE sends the SIP INVITE request, containing an initial SDP, to the P-CSCF address determined with P-CSCF discovery mechanism. The initial SDP may represent one or more media for a multi-media session.
Step 2.
A connection is reserved in the C-BGF with optional NAT binding list retrieval.
Step 3.
P-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case it forwards the INVITE to the S-CSCF in the home network.
Step 4.
S-CSCF validates the service profile, and invokes any origination service logic required for this user. This includes authorization of the requested SDP based on the user's subscription for multi-media services.
Step 5.
S-CSCF forwards the request, as specified by the S-S procedures. In addition, subject to operator policy, the S-CSCF may insert in the request a reference location of the user, when network-provided location information is not already present. The reference location (e.g. line identification) is determined by the operator as part of the user profile and may be received from the HSS at registration.
Step 6.
The media stream capabilities of the destination are returned along the signalling path, per the S-S procedures.
Step 7-9.
S-CSCF forwards the Offer Response message to the P-CSCF which triggers RACS. RACS performs admission control based on the Offer and Answer parameters.
RACS configures the connections in the C-BGF based on the SDP answer and optionally requests a NAT binding list.
Step 10.
UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends the Response Confirmation to P-CSCF. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response received in step 9 or a subset. If new media are defined by this SDP, a new connection configuration shall be performed following step 2. The originating UE is free to continue to offer new media in this request or in subsequent requests using the Update method. Each offer/answer exchange will cause the P-CSCF to repeat the RACS interactions again.
Step 11.
P-CSCF forwards this message to S-CSCF
Step 12.
S-CSCF forwards this message to the terminating endpoint, as per the S-S procedure.
Step 13.
The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If the SDP has changed, the admission control and configure connection flows are repeated.
Step 14-15.
S-CSCF and P-CSCF forward the answered media towards the UE.
Step 16-18.
The destination UE may optionally perform alerting. If so, it signals this to the originating party by a provisional response indicating Ringing. This message is sent to S-CSCF per the S-S procedure. It is sent from there toward the originating end along the signalling path. UE indicates to the originating user that the destination is ringing.
Step 19-20.
When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the signalling path to the originating endpoint, as specified by the termination procedures and the S-S procedures.
Step 21.
P-CSCF performs the approval of QoS Commit procedure which triggers the Open Gates procedures if required.
Step 22.
P-CSCF passes the 200-OK response back to UE.
Step 23.
UE starts the media flow(s) for this session.
Step 24-26.
UE responds to the 200 OK with an ACK message which is sent to P-CSCF and passed along the signalling path to the terminating endpoint.
Up

N.2  Termination proceduresWord‑p. 271

N.2.1  (FT#1) Fixed xDSL termination, home

This termination procedure applies to users located in their home service area. As in clause 5.7.2, the UE is located in the home network, but has registered to the IM CN Subsystem via an xDSL IP-CAN.
(not reproduced yet)
Figure N.2.1: Fixed xDSL terminating - home (example flow)
Up
Procedure FT#1 is as follows:
Step 1.
UE#1 sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures and the S-S procedures, to the S-CSCF for the terminating UE.
Step 2.
S-CSCF validates the service profile, and invokes any termination service logic required. This includes authorization of the requested SDP based on the user's subscription for multi-media services.
Step 3.
S-CSCF remembers (from the registration procedure) the P-CSCF address for this UE. The S-CSCF forwards the INVITE to the P-CSCF, which in this case is located in the home network.
Step 4.
The P-CSCF triggers RACS which reserves a connection in C-BGF with optional NAT binding retrieval.
Step 5.
P-CSCF remembers (from the registration procedure) the UE address, and forwards the INVITE to the UE.
Step 6.
UE determines the subset of the media flows proposed by the originating endpoint that it is capable and willing to support, and responds with an Offer Response message back to the originator. The SDP may represent one or more media for a multi-media session. This response is sent to the P-CSCF.
Step 7.
P-CSCF triggers RACS to perform admission control based on Offer and Answer parameters.
RACS configures the connection in the C-BGF based on SDP answer with optional NAT binding retrieval.
Step 8.
P-CSCF forwards the Offer Response message to S-CSCF.
Step 9.
S-CSCF forwards the Offer Response message to the originator, per the S-S procedure.
Step 10-15.
The originating endpoint sends a Response Confirmation via the S-S procedure, to the terminating S-CSCF. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent in step 19 or a subset. If new media are defined by this SDP, a new interaction with the RACS (as in steps 4-8) will be done by the P-CSCF. The originating UE is free to continue to offer new media in this request or in a subsequent request using the Update method. Each offer/answer exchange will cause the P-CSCF to repeat the RACS interactions (steps 4-8) again.
Step 16-18.
UE may alert the user and wait for an indication from the user before completing the session. If so, it indicates this to the originating party by a provisional response indicating Ringing. This message is sent to P-CSCF and along the signalling path to the originating endpoint.
Step 19.
When the destination party answers, UE sends a SIP 200 OK final response to P-CSCF.
Step 20.
P-CSCF indicates that the resources reserved for this session should now be committed.
Step 21-22.
P-CSCF forwards the 200 OK to S-CSCF, following the signalling path.
Step 23-25.
The session originator responds to the 200 OK by sending the ACK message to S-CSCF via the S-S procedure and it is forwarded to the terminating end along the signalling path.
Up

N.3  Geographical Identifier |R12|Word‑p. 272
For fixed xDSL, Fiber or Ethernet access, Geographical Identifier may be used within the IMS as described in clause E.8.

P  Transcoding Support involving the MRFC/MRFP |R8|Word‑p. 273

P.1  General

P.1.1  Scope

This clause describes media transcoding services involving the MRFC/MRCP applicable in the following cases:
  • between two IMSs;
  • between an IMS and other SIP based multimedia network; and
  • internal to an IMS servicing media endpoints with different media encoding requirements. This can arise due to support of different access technologies (e.g. wireline-wireless interworking, or support of non-3GPP wireless technologies), or from divergence in supported or allowed media encoding formats (e.g. configuration of devices to only allow certain codecs).
The MRFC and MRFP act as transcoding entity in an IMS solving media encoding mismatches due to codec selection between operator networks, as well as to deal with encoding formats in a converged service environment.
Up

P.1.2  Description

Application Servers can invoke the MRFC for the purpose of media transcoding between UEs that have no supported codec in common. The MRFC controls functionality in the MRFP to perform media plane transcoding.
The decision to perform media transcoding requires knowledge of the codecs supported by the calling and called UEs. Media transcoding services can be triggered proactively (before the session request is sent to the called UE) or reactively (after the session request has been sent to, and rejected by, the called UE). Proactive transcoding invocation requires prior knowledge of the codecs supported by the UE at which the called party is registered. In the case of reactive transcoding the list of codecs supported by the called UE is carried in the SIP response message.
Up

P.1.3  Session flows

P.1.3.1  General

The following use cases illustrate session procedures involving the MRFC required to support transcoding between UEs due to error cases or incompatible terminal equipment. In addition, transcoding procedures are applicable to both the originating and the terminating side of the session or even (in inter-network scenarios) in a transit network, and are subject to bilateral agreements and operator configuration. A media transcoding session refers to a SIP session between an entity in the IMS control plane (hereafter referred to as the "invoking function") and the MRFC/MRFP as actual transcoding device, setup for the purpose to mediate between calling and called UEs. The SIP session between the invoking function and the MRFC is used to reserve resources at the transcoding unit, in this case the MRFP, and to exchange transport address and port information. The session flows described here have been simplified by abbreviating the message exchange, e.g., by eliminating 100 trying messages. Similar session flows are available in Annex B of TS 23.218.
Up

P.1.3.2  Proactive transcoding invocation

As noted above, proactive transcoding invocation requires prior knowledge of the codecs supported by the UE at which the called party is registered. At session initiation the calling UE capabilities are contained in the SDP offer, while called UE capabilities can be either preconfigured or known by other means in the network (e.g. if the control plane entity responsible for detecting the need of transcoding previously learned the codecs supported by the UE that is now called by monitoring session requests initiated by it).
The following session flow illustrates proactive media transcoding:
(not reproduced yet)
Figure P.1.3.2-1: Proactive transcoding triggering logic
Up
Step 1.
Calling UE sends a SIP request targeted at an address registered at the called UE, including an SDP offer containing codec(s) and the IP address and TCP or UDP port number at which the calling UE wishes to receive media.
Step 2.
The SIP request is received by an IMS control plane entity responsible for detecting the need of proactive transcoding invocation. If the SDP offer does not include any codec supported by the called UE, then the invoking function is triggered to set up a SIP session with the MRFC, providing codecs and transport parameters to initiate a transcoding session.
Step 3.
The invoking function instructs the MRFC to:
  • allocate media processing resources from an MRFP entity under the MRFC's control, configured with the address and port at which the calling UE wishes to receive media, using a codec (say, codec-A) previously included by the calling UE in the SDP offer and hence known to be supported;
  • allocate media processing resources from the same MRFP entity to the called UE, using a codec (say, codec-B) known to be supported by the called UE; and
  • cause the MRFP entity to bridge those two media flows, such that media received on one will be converted to the format of and transmitted on the other.
The MRFC accepts the transcoding request and contacts an MRFP to allocate the requested resources. The MRFP responds with the IP address and port number associated with each requested codec. The MRFC returns this information to the invoking function.
Step 4.
The invoking function updates the SIP request received in step 1 by appending codec-B to the list of codecs in the SDP offer (after all codecs that were previously in the offer), and altering the transport address and port information to indicate the addresses associated by the MRFP with its resources of type codec-B.
Step 5.
Called UE acknowledges the SDP offer and makes a codec selection (codec-B), providing also its actual IP address/port number information in the SDP answer.
Step 6.
Upon receipt of the answer from the called UE, the invoking function updates the session with the MRFC (providing the codec selected and the address /port information from the SDP answer). The MRFC processes the received information to configure the transcoding unit with the codec, the destination address and port towards the called UE.
Step 7.
The invoking function modifies the SDP answer to reference codec-A, and the transport address and port information to indicate the addresses associated by the MRFP with its resources of type codec-A. The invoking function forwards the SIP message containing the SDP answer to the calling UE.
Up

P.1.3.3  Reactive transcoding invocationWord‑p. 275
Reactive invocation of media transcoding is useful in the case that the calling and called UE support no common codec, and for whatever reason transcoding is not proactively invoked. In this case the SDP offer received by the called UE contains no codecs that the called UE supports. The called UE will answer with an appropriate SIP error response, which can include information about actually supported codecs. Transcoding invoked in response to receipt of such an error response is termed Reactive.
The following example session flow describes reactive invocation of media transcoding:
(not reproduced yet)
Figure P.1.3.3-1: Reactive transcoding triggering logic
Up
Step 1.
Calling UE sends a SIP request, including an SDP offer containing codec(s) and the IP address and TCP or UDP port number at which calling UE wishes to receive media. For some reason, e.g. because proactive invocation of media transcoding is not supported in the terminating network, transcoding is not proactively invoked.
Step 2.
The called UE or a terminating network entity (such as MGCF) determines that it does not support any codec in the SDP offer and answers with an appropriate error response. This response can include a list of codecs that the called UE can support.
Step 3.
Based on the response from called UE indicating that it does not support the offered codecs, an IMS control plane entity responsible for detecting the need of reactive transcoding invocation triggers the invoking function to set up a SIP session with the MRFC, providing codecs and transport parameters to initiate a transcoding session.
Step 4.
The invoking function instructs the MRFC to:
  • allocate media processing resources from an MRFP entity under the MRFC's control, configured with the address and port at which the calling UE wishes to receive media, using a codec (say, codec-A) previously included by calling UE in the SDP offer hence known to be supported by calling UE;
  • allocate media processing resources from the same MRFP entity to called UE, using a codec (say, codec-B) known to be supported by called UE; and
  • cause the MRFP entity to bridge those two media flows, such that media received on one will be converted to the format of and transmitted on the other.
The MRFC accepts the transcoding request and contacts an MRFP to allocate the requested resources. The MRFP responds with the IP address and port number associated with each requested codec. The MRFC returns this information to the invoking function.
Step 5.
Based on the information received from the MRFC, the invoking function creates a new SDP offer that contains the information provided by the MRFC (codec and transport addresses). If no information about supported codecs was available from the error response, the invoking function offers all codecs supported by the transcoding device. It sends this offer to the called UE.
Step 6.
Called UE acknowledges the SDP offer and makes a codec selection, providing in the SDP answer the IP address and TCP or UDP port at which it wants to receive media.
Step 7.
Upon receipt of the answer from the called UE, the invoking function updates the session with the MRFC (providing the codec selected and the address /port information from the SDP answer). The MRFC processes the received information to configure the transcoding unit with the codec, the destination address and port towards the called UE.
Step 8.
The invoking function modifies the SDP answer received from the called UE such that it refers to codec-A and the MRFP address and port number associated with it in step 4, and sends this message to the calling UE. The session between the end points is now established with the media flow traversing the transcoding device.
Up


Up   Top   ToC