A.6 Loopback routeing via an intermediate network
29.0793GPPOptimal media routeing within the IP Multimedia Subsystem (IMS)Release 17Stage 3TS
A.6.1 General
This clause provides an example on how OMR is used to find an optimal media path when loopback routeing is used and how to preserve signalling paths and media paths compatible with the existing CS charging model.
The example does not focus on the OMR algorithm as such instead the focus is on the selection and configuration of IP realm names. The example only describes the message flow on the originating side.
Figure A.6.1-1 shows the IP realm and IP configuration used in this example.
Figure A.6.1-1: IP realm and IP address configurations
A.6.2 Message flow
The user A at UE-A is roaming into a visited network V. The user A is a subscriber of operator H.
Preconditions in this example:
– The user A is registered to the Home IMS network H via the visited operator V network and the IC network X; The IC network does not store any registration information.
– P-CSCF-A and S-CSCF support loopback routeing;
– IBCF-1, IBCF-2, IBCF-3, IBCF-4, IBCF-5, IC-1 and IC-2 support OMR and all networks supports loopback routeing;
– IBCF-1, IBCF-4 and IBCF-5 are instances in the same physical IBCF in the visited network V;
– IC-1 and IC-2 are instances in the same physical IC hub;
– IBCF-2 and IBCF-3 are instances in the same physical IBCF in the home network H; and
– no B2BUA manipulating SDP is connected in the home operator H network.
The "iotl" SIP URI parameter specified in IETF RFC 7549 [22] is included in the message flow in order to assist in determine the policy.
Figure A.6.2-1 shows the message flow for the scenario.
Figure A.6.2-1: Message flow for loopback routeing via an IC network
NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow.
The steps of the flow are as follows:
1. INVITE request (UE-A to P-CSCF-A) – see example in table A.6.2-1.
The user A at UE-A initiates a call. The UE-A sends an initial INVITE request containing an initial SDP offer to the P-CSCF-A according to TS 24.229 [4].
Table A.6.2-1: INVITE request (UE-A to P-CSCF-A)
INVITE SIP: tel:+4687197378; SIP/2.0
Route: <sip:pcscf1.visitedV.net;lr>
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 49170 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
2. INVITE request (P-CSCF-A to IBCF-1) – see example in table A.6.2-2.
When the P-CSCF-A receives the initial INVITE request and, since the user A is a roaming user, the P-CSCF-adds the Feature-Caps header field with the g.3gpp.trf with the address to the TRF; and
The P-CSCF-A selects an IBCF (IBCF-1) to be the exit IBCF towards the home IMS network H of the user A and sends the INVITE request without modifying the initial SDP offer according to TS 24.229 [4] to IBCF-1.
Table A.6.2-2: INVITE request (P-CSCF-A to IBCF-1)
INVITE SIP: tel:+4687197378; SIP/2.0
Route: <sip:scscf1.operatorH.net;lr;iotl=visitedA-homeA>
Feature-Caps:*;+g.3gpp.trf="<sip:trf1.visitedV.net;iotl=homeA-visitedA>"
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 49170 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
3. INVITE request (IBCF-1 to IC-1) – see example in table A.6.2-3.
When the IBCF-1 receives the initial INVITE request containing the "+g.3gpp.trf" header field parameter in a Feature-Caps header field, the IBCF-1 updates the SDP as follows:
– the media parameters received from the TrGW are included in the initial SDP offer;
– the IP address, port number and the IP realm Va.operatorV.net of the UE-A is included as the visited-realm 1 instance;
– the IP address, port number of the TrGW and the local IP realm Xa1.operatorX.net are included as the visited-realm 2 instance. To avoid unwanted optimal media paths being created the local IP realm Xa1.operatorX.net is selected as this is a local IP realm only known by the IBCF-1, IBCF-4 and IBCF-5.
The IBCF-1 selects to route the INVITE request via an IC network and sends the INVITE request with the modified SDP offer according to TS 24.229 [4] to the IC-1.
Table A.6.2-3: INVITE request (IBCF-1 to IC-1)
INVITE SIP: tel:+4687197378; SIP/2.0
Route: <sip:scscf1.operatorH.net;lr;iotl=visitedA-homeA>
Feature-Caps:*;+g.3gpp.trf="<sip:trf1.visitedV.net;iotl=homeA-visitedA>"
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 178.15.1.1
m=audio 62111 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=omr-m-cksum:(..)
a=omr-s-cksum:0
4. INVITE request (IC-1 to IBCF-2) – see example in table A.6.2-4.
When the IC-1 receives the initial INVITE request and since the IC-1 according to local policy allows itself to be bypassed by media then the IC-1 updates the initial SDP offer as follows:
– the media parameters of the IC-1 are included in the initial SDP offer; and
– the IP address, port number of the IC-1 and the local IP realm Xa2.operatorX.net are included as the visited-realm 3 instance. To avoid unwanted optimal media paths being created the local IP realm Xa2.operatorX.net is selected as this is a local IP realm only known by the IC-1 and IC-2.
The IC-1 selects an entry IBCF of the home IMS network H and sends the INVITE request with the modified initial SDP offer according to TS 24.229 [4] to the IBCF-2.
Table A.6.2-4: INVITE request (IC-1 to IBCF-2)
INVITE SIP: tel:+4687197378; SIP/2.0
Route: <sip:scscf1.operatorH.net;lr;iotl=visitedA-homeA>
Feature-Caps:*;+g.3gpp.trf="<sip:trf1.visitedV.net;iotl=homeA-visitedA>"
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi="Va.operatorV.net"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 179.14.1.1
m=audio 52211 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211
a=omr-m-cksum:(..)
a=omr-s-cksum:0
5. INVITE request (IBCF-2 to S-CSCF) – see example in table A.6.2-5.
When the IBCF-2 receives the initial INVITE request containing the "+g.3gpp.trf" header field parameter in a Feature-Caps header field, the IBCF-2 updates the initial SDP offer as follows:
– the media parameters of the TrGW are included in the initial SDP offer; and
– the IP address, port number of the TrGW and the IP realm Ha.operatorH.net are included as the visited-realm 4 instance.
The IBCF-2 sends the INVITE request with the modified initial SDP offer according to TS 24.229 [4] to the S-CSCF.
Table A.6.2-5: INVITE request (IBCF-2 to S-CSCF)
INVITE SIP: tel:+4687197378; SIP/2.0
Route: <sip:scscf1.operatorH.net;lr;iotl=visitedA-homeA>
Feature-Caps:*;+g.3gpp.trf ="<sip:trf1.visitedV.net;iotl=homeA-visitedA>"
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi="Va.operatorV.net"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 190.1.15.1
m=audio 16789 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211
a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789
a=omr-m-cksum:(..)
a=omr-s-cksum:0
6. INVITE request (S-CSCF to IBCF-3) – see example in table A.6.2-6.
When the S-CSCF receives the initial INVITE request the S-CSCF decides according to local policy that loopback routeing shall be used.
The S-CSCF:
– includes the TRF URI included in the g.3gpp.trf in the Route header field; and
– includes in a Feature-Caps header field the feature tag +g.3gpp.loopback to indicate that loopback routeing is ongoing.
NOTE: Number normalization and ENUM translation is deferred to the visited network.
The S-CSCF/BGCF selects an entry IBCF and sends the INVITE request with the modified SDP offer according to TS 24.229 [4] to the IBCF-3.
Table A.6.2-6: INVITE request (S-CSCF to IBCF-3)
INVITE SIP: tel:+4687197378; SIP/2.0
Route:<sip:trf1.visitedV.net;lr;iotl=homeA-visitedA>
Feature-Caps:*;+g.3gpp.loopback=<"homenetwork_A">
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 190.1.15.1
m=audio 16789 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211
a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789
a=omr-m-cksum:(..)
a=omr-s-cksum:0
7. INVITE request (IBCF-3 to IC-2) – see example in table A.6.2-7.
When the IBCF-3 receives the initial INVITE request containing the "+g.3gpp.loopback" header field parameter in a Feature-Caps header field, the IBCF-3 updates the initial SDP offer as follows:
– the media parameters of the TrGW are included in the initial SDP offer; and
– the IP address, port number of the TrGW and the local IP realm Xa4.operatorX.net are included as the visited-realm 5 instance. To avoid unwanted optimal media paths being created the local IP realm Xa4.operatorX.net is selected as this is a local IP realm only known by the IBCF-2 and IBCF-3.
The IBCF-3 selects to route the INVITE request via an IC network and sends the INVITE request with the modified initial SDP offer according to TS 24.229 [4] to the IC-2.
Table A.6.2-7: INVITE request (IBCF-3 to IC-2)
INVITE SIP: tel:+4687197378; SIP/2.0
Route:<sip:trf1.visitedV.net;lr;iotl=homeA-visitedA>
Feature-Caps:*;+g.3gpp.loopback=<"homenetwork-A">
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 179.14.1.3
m=audio 34500 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211
a=visited-realm:4 Ha.operatorH.net IN IP4 190.1.15.1 16789
a=visited-realm:5 Xa4.operatorX.net IN IP4 179.14.1.3 34500
a=omr-m-cksum:(..)
a=omr-s-cksum:0
8. INVITE request (IC-2 to IBCF-4) – see example in table A.6.2-8.
When the IC-2 receives the initial INVITE request the IC-2 detects that an optimal media path avoiding media to be sent through the home IMS network H is possible. The IC-2 updates the initial SDP offer as follows:
– the IP address and port number included by IC-1 in visited-realm instance 3 are included in the initial SDP offer; and
– the visited-realm instances 4 and 5 are removed so that the media path is no longer passing the home IMS network H.
The IC-2 selects an entry IBCF in the visited network and sends the INVITE request with the modified initial SDP offer according to TS 24.229 [4] to the IBCF-4.
Table A.6.2-8: INVITE request (IC-2 to IBCF-4)
INVITE SIP: tel:+4687197378; SIP/2.0
Route:<sip:trf1.visitedV.net;lr;iotl=homeA-visitedA>
Feature-Caps:*;+g.3gpp.loopback=<"homenetwork-A">
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 179.14.1.1
m=audio 52211 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=visited-realm:2 Xa1.operatorX.net IN IP4 178.15.1.1 62111
a=visited-realm:3 Xa2.operatorX.net IN IP4 179.14.1.1 52211
a=omr-m-cksum:(..)
a=omr-s-cksum:0
9. INVITE request (IBCF-4 to TRF) – see example in table A.6.2-9.
When the IBCF-4 receives the initial INVITE request containing the "+g.3gpp.loopback" header field parameter in a Feature-Caps header field, the IBCF-4 searches for a possible optimal media path and detects that an optimal media path within the visited network is possible. The IBCF-4 updates the initial SDP offer as follows:
– the IP address and port numbers in the visited-realm instance 1 is included in the initial SDP offer; and
– the visited-realm instances 2 and 3 are removed so that the media path is no longer passing the IC network.
The IBCF-4 sends the INVITE request with the modified initial SDP offer according to TS 24.229 [4] to the TRF.
Table A.6.2-9: INVITE request (IBCF-4 to TRF)
INVITE SIP: tel:+4687197378; SIP/2.0
Route:<sip:trf1.visitedV.net;lr;iotl=homeA-visitedA>
Feature-Caps:*;+g.3gpp.loopback=<"homenetwork-A">P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 49170 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=omr-m-cksum:(..)
a=omr-s-cksum:0
10. INVITE request (TRF to IBCF-5) – see example in table A.6.2-10.
When the TRF receives the initial INVITE request the TRF:
– performs number normalization and ENUM translation and updates the Request-URI if necessary; and
– appends "iotl" SIP URI parameter with the value "visitedA-homeB" to the Request-URI.
The TRF selects an exit IBCF and sends the INVITE request with the unmodified initial SDP offer according to TS 24.229 [4] to the IBCF-5.
Table A.6.2-10: INVITE request (TRF to IBCF-5)
INVITE SIP: <sip:+46107197378@operatorY;user=phone;iotl=visitedA-homeB> SIP/2.0
P-Access-Network-Info:3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi="Va.operatorV.net"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=
t=0 0
c=IN IP4 192.0.2.1
m=audio 49170 RTP/AVP 96 97
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:96 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.1 49170
a=omr-m-cksum:(..)
a=omr-s-cksum:0
11. 183 (Session Progress) response (IBCF-5 to TRF) – see example in table A.6.2-11.
When the IBCF-5 receives the initial INVITE request the IBCF-5 sends the INVITE request towards the terminating network. The INVITE request may or may not include OMR specific parameters based on the IBCF-5 local policy.
When the IBCF-5 receives an initial SDP answer in a 183 (Session Progress) response from the terminating network the IBCF-5:
– includes its own IP address and port number received from the TrGW in the initial SDP answer.
The IBCF sends the 183 (Session Progress) response with the modified initial SDP answer according to TS 24.229 [4] to the TRF.
Table A.6.2-11: 183 (Session Progress) response (IBCF-5 to TRF)
SIP/2.0 183 Session Progress
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";term-ioi="y.operatorY.net"
Other SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.4 16511
12. 183 (Session Progress) response (TRF to IBCF-4) – see example in table A.6.2-12.
When the TRF receives the 183 (Session Progress) response the TRF stores the received term-ioi; and
The TRF sends the 183 (Session Progress) response with the unmodified initial SDP answer according to TS 24.229 [4] to the IBCF-4.
Table A.6.2-12: 183 (Session Progress) response (TRF to IBCF-4)
SIP/2.0 183 Session Progress
SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.4 16511
13-15. 183 (Session Progress) response (IBCF-4 to S-CSCF via IC-2 and IBCF-3) – see example in table A.6.2-13.
When the IBCF-4 receives the 183 (Session Progress) response the IBCF-4 updates the initial SDP answer as follows:
– The c=IN IP4 192.0.2.4 is replaced with an invalid IPv4 address, i.e. c=IN IP4 0.0.0.0, since the IP realm on visited network side and the IC network side are not the same hence the received IP address is not valid on the IC side.
The IBCF-4 sends the 183 (Session Progress) response with the modified initial SDP answer according to TS 24.229 [4] towards the S-CSCF via the IC-2 and IBCF-3. Neither the IC-2 nor the IBCF-3 updates the SDP.
Table A.6.2-13: 183 (Session Progress) response (IBCF-4 to S-CSCF via IC-2 and IBCF-3)
SIP/2.0 183 Session Progress
SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.4 16511
16-18. 183 (Session Progress) response (S-CSCF to IBCF-1 via IBCF-2 and IC-1) – see example in table A.6.2-16.
The S-CCSCF sends the 183 (Session Progress) response according to TS 24.229 [4] to the IBCF-1. Neither the IBCF-2 nor IC-1 updates the initial SDP answer.
Table A.6.2-16: 183 (Session Progress) response (S-CSCF to IBCF-1 via IBCF-2 and IC-1)
SIP/2.0 183 Session Progress
SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
a=visited-realm:1 Va.operatorV.net IN IP4 192.0.2.4 16511
19. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) – see example in table A.6.2-19.
When the IBCF-1 receives the 183 (Session Progress) response the IBCF-1 updates the initial SDP answer.
The IBCF-1:
– replaces the received invalid IPv4 address with the IP address received in the visited-realm instance 1; and
– removes all OMR specific attributes since the initial SDP offer from P-CSCF-A did not contain any OMR specific attributes.
The IBCF-1 sends the 183 (Session Progress) response with the modified initial SDP answer according to TS 24.229 [4] to the P-CSCF-A.
Table A.6.2-19: 183 (Session Progress) response (IBCF-1 to P-CSCF-A)
SIP/2.0 183 Session Progress
SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
20. 183 (Session Progress) response (P-CSCF-A to UE-A) – see example in table A.6.2-20.
When the P-CSCF-A receives the 183 (Session Progress) response the P-CSCF authorizes the resources;
The P-CSCF-A sends the 183 (Session Progress) response with the unmodified initial SDP answer according to TS 24.229 [4] to the UE-A.
Table A.6.2-20: 183 (Session Progress) response (P-CSCF-A to the UE-A)
SIP/2.0 183 Session Progress
SIP headers according to 3GPP TS 24.229 [4]
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 16511 RTP/AVP 97 98
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 AMR
a=fmtp:98 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
21. PRACK requests and SIP 200 (OK) response to the SIP PRACK request
The PRACK is sent without any SDP offer/SDP answer between the UE-A and IBCF-5 according to TS 24.229 [4].
22. UPDATE request and SIP 200 (OK) response to the SIP UPDATE request
The UPDATE request and the 200 (OK) response to the UPDATE request is sent with a subsequent SDP offer and subsequent SDP answer following the same principle as in clause A.3.2 steps 33 – 48 but now indicating that resources are reserved at UE-A.
23. 180 (Ringing) response to INVITE request
The remote UE sends a 180 (Ringing) response when resources are reserved. The remote UE does not have to send an UPDATE request to indicate that resources are reserved since the subsequent SDP offer did not include the "a=conf" attribute.
When the IBCF-5 receives the response the IBCF-5 forwards the response to the UE-A via all intermediate nodes. There are no OMR specific actions since the 180 (Ringing) response does not contain any SDP.
24. 200 (OK) response to INVITE request and the SIP ACK request
The 200 (OK) response to the initial INVITE request is sent according to TS 24.229 [4] between the IBCF-5 and UE-A via all intermediate nodes as specified in TS 24.229 [4].
The ACK request is sent according to TS 24.229 [4] between the UE-A and IBCF-5 via all intermediate nodes as specified in TS 24.229 [4].
Annex B (informative):
Change history
|
Change history |
|||||||||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
||||||
|
11.30.10 |
Version 1.0.0 was created by MCC |
0.3.0 |
1.0.0 |
||||||||||
|
01.31.11 |
Version 1.1.0 created by rapporteur based on PCRs C3-110028, C3-110030, C3-110031, C3-110032, C3-110033, C3-110034, C3-110233, C3-110234, C3-110235, C3-110238, C3-110374, C3-110375, C3-110376 |
1.0.0 |
1.1.0 |
||||||||||
|
02.28.11 |
Version 1.2.0 created by rapporteur based on PCRs C3-110472, C3-110579, C3-110580, C3-110582,C3-110601, C3-110603, C3-110604, C3-110605, C3-110650, C3-110651, C3-110696, C3-110699, C3-110723, C3-110755 |
1.1.0 |
1.2.0 |
||||||||||
|
03/2011 |
TSG#51 |
3GPP TS 29.079 2.0.0 have been approved in TSG#51 |
2.0.0 |
10.0.0 |
|||||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0001 |
2 |
Adding session checksum in the simple example flow |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0002 |
2 |
Update of proactive transcoder without resource reservation FLOW |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0003 |
3 |
Clarifying checksum calculation |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0004 |
3 |
Receiving and modified SDP offer clarification |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0005 |
2 |
IMS-ALG bypasses an allocated transcoding MR – FLOW |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0006 |
2 |
Enhanced IP realm definition |
10.0.0 |
10.1.0 |
||||||
|
06/2011 |
TSG#52 |
CP-110408 |
0007 |
2 |
Making connected IP realm information available |
10.0.0 |
10.1.0 |
||||||
|
09/2011 |
TSG#53 |
Editorial Improvement by MCC |
10.1.0 |
10.1.1 |
|||||||||
|
12/2011 |
TSG#54 |
CP-110834 |
0008 |
Updated references – Media Control Channel Framework |
10.1.1 |
10.2.0 |
|||||||
|
06/2012 |
TSG#56 |
CP-120355 |
0009 |
3 |
RAVEL Loop-back routeing example updates |
10.2.0 |
11.0.0 |
||||||
|
06/2012 |
TSG#56 |
CP-120357 |
0010 |
Incorrect IP address in example |
10.2.0 |
11.0.0 |
|||||||
|
09/2012 |
TSG#57 |
CP-120535 |
0013 |
OMR modification |
11.0.0 |
11.1.0 |
|||||||
|
09/2012 |
TSG#57 |
CP-120535 |
0014 |
1 |
Naming of transit network |
11.0.0 |
11.1.0 |
||||||
|
12/2012 |
TSG#58 |
CP-120840 |
0015 |
1 |
Updating loopback example |
11.1.0 |
11.2.0 |
||||||
|
12/2012 |
TSG#58 |
CP-120827 |
0018 |
Reference update of draft-ietf-mediactrl-mixer-control-package |
11.1.0 |
11.2.0 |
|||||||
|
12/2012 |
TSG#58 |
CP-120827 |
0020 |
2 |
OMR Signalling Flows |
11.1.0 |
11.2.0 |
||||||
|
03/2013 |
TSG#59 |
CP-130079 |
0016 |
4 |
Identifying an RAVEL session |
11.2.0 |
11.3.0 |
||||||
|
03/2013 |
TSG#59 |
CP-130079 |
0021 |
Removing all editors notes in the loopback flow |
11.2.0 |
11.3.0 |
|||||||
|
06-2014 |
TSG#64 |
CP-140362 |
0024 |
2 |
Correcting IP addresses on OMR call flow examples |
11.3.0 |
11.4.0 |
||||||
|
06-2014 |
TSG#64 |
CP-140382 |
0022 |
1 |
II-NNI traversal scenario identification |
11.3.0 |
12.0.0 |
||||||
|
09-2014 |
CT-65 |
CP-140528 |
0028 |
– |
Correcting references |
12.0.0 |
12.1.0 |
||||||
|
09-2014 |
CT-65 |
CP-140528 |
0032 |
1 |
Message flow correction for media bypassing all IMS-ALGs |
12.0.0 |
12.1.0 |
||||||
|
09-2014 |
CT-65 |
CP-140536 |
0026 |
1 |
Adding the "iotl" SIP URI parameter in the loopback message flow |
12.0.0 |
12.1.0 |
||||||
|
09-2014 |
CT-65 |
CP-140553 |
0025 |
– |
Removal of a non-existing feature-capability |
12.0.0 |
12.1.0 |
||||||
|
09-2014 |
CT-65 |
CP-140553 |
0029 |
2 |
Adding missing home network identity in g.3gpp.loopback feature-capability indicator |
12.0.0 |
12.1.0 |
||||||
|
03-2015 |
CT-67 |
CP-150100 |
0036 |
Instance-number value for secondary-realm |
12.1.0 |
12.2.0 |
|||||||
|
03-2015 |
CT-67 |
CP-150100 |
0039 |
Checksum calculation |
12.1.0 |
12.2.0 |
|||||||
|
03-2015 |
CT-67 |
CP-150100 |
0042 |
Correcting UA procedure |
12.1.0 |
12.2.0 |
|||||||
|
03-2015 |
CT-67 |
CP-150109 |
0046 |
Reference update: draft-holmberg-dispatch-iotl |
12.1.0 |
12.2.0 |
|||||||
|
06-2015 |
CT-68 |
CP-150340 |
0049 |
2 |
Procedures for avoiding changes in the OMR algorithm outcome on subsequent SDP offer/answer transactions |
12.2.0 |
12.3.0 |
||||||
|
06-2015 |
CT-68 |
CP-150347 |
0050 |
– |
draft-holmberg-dispatch-iotl-parameter-04 updated to RFC 7549 |
12.2.0 |
12.3.0 |
||||||
|
12-2015 |
Automatic upgrade from previous Release |
12.3.0 |
13.0.0 |
||||||||||
|
Change history |
|||||||||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New |
||||||
|
03-2017 |
CT#75 |
Automatic upgrade from previous Release |
14.0.0 |
||||||||||
|
2018-06 |
SA-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|||||||
|
2020-06 |
SA#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|||||||
|
2021-12 |
CT#94e |
CP-213220 |
0051 |
– |
F |
Reference update: removal of RFC 2617 |
17.0.0 |
||||||