A.5 IMS-ALG bypasses an allocated transcoding MR

29.0793GPPOptimal media routeing within the IP Multimedia Subsystem (IMS)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

A.5.1 General

This clause provides an example of a call where the UE initiating a call offers the AMR codec. An IMS-ALG, IBCF-1 in figure A.2.1, adds the AMR-WB codec to the initial SDP offer and reserves an MR resource.

The terminating UE selects the AMR codec and the IMS-ALG needs to deallocate the MR and update the terminating UE with the IP addresses of the UE-A in a realm instance to allow bypassing of the IMS-ALG itself.

Figure A.5.1-1 shows the realm and IP structure used in this example.

Figure A.5.1-1: IP realm and IP structure

A.5.2 Message flow

The user A at UE-A and the user B at UE-B roams into a visited network X and both users belongs to the same operator Y.

Preconditions:

– Both users A and B are registered to the Home IMS network Y via the visited operator X network;

– the visited operator X and the operator of user A and B IMS home network Y have an agreement to allow media to be bypassed using OMR;

– both users A and B are connected to realm Xa of the visited operator network X;

– the AMR codec is allowed and accepted by all involved entities. However, the local policy of operator X is that the AMR-WB codec shall always be included in the initial SDP offers from the operator X network; and

– no B2BUA manipulating SDP is connected in the intermediate IM CN subsystem.

Figure A.5.2-1 shows the message flow for the scenario.

Figure A.5.2-1: Message flow for transcoder with resource reservation, codec not selected

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.5.2-1.

The UE-A sends a SIP INVITE request according to TS 24.229 [4]. The INVITE request includes an initial SDP offer proposing the use of the AMR codec and inband DTMF.

Table A.5.2-1: SIP INVITE request (UE-A to P-CSCF-A)

INVITE SIP: user_B@operator_Y.net; SIP/2.0

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

b=AS:30

b=RS:0

b=RR:2000

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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=ptime:20

a=maxptime:240

2. INVITE request (P-CSCF-A to IBCF-1) – see example in table A.5.2-1.

The P-CSCF-A uses the procedures in clauses 6.1.5, 6.1.7 and 6.1.9 since no MR could be bypassed and no MR is allocated.

The P-CSCF-A:

– uses the connection-address from the SDP c-line as incoming connection-address;

– uses the port information from the SDP m-line as incoming port information;

– uses the codec information from the SDP m-line;

– inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified initial SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded initial SDP offer, and

– use the incoming port information as port information in the SDP m-line of the modified initial SDP offer.

The P-CSCF-A then selects an IBCF, IBCF-1, in the realm "Xa.operatorX.net" and forwards the INVITE request with the initial SDP offer to the IBCF-1 according to TS 24.229 [4].

3. INVITE request (IBCF-1 to IBCF-2) – see example in table A.5.2-3

The IBCF-1 uses the procedures in 6.1.5, 6.1.6 and 6.1.9 since IBCF-1 determines according to local policy that a transcoding MR is needed and that there is no previous MR to bypass.

The IBCF-1:

– uses the connection-address from the SDP c-line in the received SDP offer as incoming connection-address in subsequent steps;

– uses the port information from the SDP m-line in the received SDP offer as incoming port information in subsequent steps;

– uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received SDP offer as incoming codec information in the subsequent steps;

– allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming connection address and port information and the outgoing signalling path;

– inserts the incoming connection address and incoming port information for the media line into the remote connection address and port information for the incoming termination on the MR;

– provides to the MR the incoming codec information;

– constructs a visited-realm instance 1;

– replaces the connection address and port information for the media line in the initial SDP offer with the connection address and port information from the MR termination on the outgoing side;

– adds a AMR-WB codec changes to incoming codec information, according to local policy, taking into account the procedures in clause 5.4, and insert the changed codec information into the SDP m-line and associated attribute lines of the modified initial SDP offer;

– provides to the MR the modified codec information;

– adds to the modified initial SDP offer a visited-realm instance 2 for the IP realm associated with the connection address and port information for the media line in the modified initial SDP offer, including the incoming codec information encoded according to clause 5.2;

– computes checksum values as described in clause 5.6.3 and adds the "omr-s-cksum" and "omr-m-cksum" attributes for the media line. The "omr-s-cksum" is set to "0" since there is no session line attributes to compute the checksum on; and

– selects an IBCF, IBCF-2, in the realm "Xa.operatorX.net" and forwards the INVITE request with the modified initial SDP offer to the IBCF-2 according to TS 24.229 [4].

Table A.5.2-3: SIP INVITE request (IBCF-1 to IBCF-2)

INVITE SIP: user_B@operator_Y.net; SIP/2.0

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

c=IN IP4 192.0.2.5

m=audio 62111 RTP/AVP 96 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=220

a=ptime:20

a=maxptime:240

b=AS:30

b=RS:0

b=RR:2000

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.1 49170

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111

a=omr-codecs:2 audio RTP/AVP 96 97

a=omr-m-att:2 rtpmap:96

a=omr-m-att:2 telephone-event

a=omr-m-att:2 rtpmap:97 AMR/8000/1

a=omr-m-att:2 fmtp:97

a=omr-m-att:2 mode-change-capability=2; max-red=220; octet-align=1

a=omr-m-att:2 curr:qos local none

a=omr-m-att:2 curr:qos remote none

a=omr-m-att:2 des:qos mandatory local sendrecv

a=omr-m-att:2 des:qos none remote sendrecv

a=omr-m-att:2 ptime:20

a=omr-m-att:2 maxptime:240

a=omr-s-bw:2 AS:30

a=omr-s-bw:2 RS:0

a=omr-s-bw:2 RR:2000

a=omr-m-cksum:(..)

a=omr-s-cksum:0

4-5. INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities) – see example in table A.5.2-4

The IMS-ALG uses the procedures in clauses 6.1.5, 6.1.6 and 6.1.9 since no MR can be bypassed and a local MR is needed for realm matching.

The IBCF-2:

– uses the connection-address from the SDP c-line as incoming connection-address in subsequent steps;

– uses the port information from the SDP m-line as incoming port information in subsequent steps;

– uses the codec information from the SDP m-line and associated non-OMR attribute lines as incoming codec information in the subsequent steps.

– allocates an MR context with access to the IP realms, nettypes and addrtypes associated with the incoming connection address and port information and the outgoing signalling path;

– inserts the incoming connection address and incoming port information for the media line into the remote connection address and port information for the incoming termination on the MR;

– provides to the MR the incoming codec information;

– replaces the connection address and port information for the media line in the initial SDP offer with the connection address and port information from the MR termination on the outgoing side;

– adds to the modified initial SDP offer a visited-realm instance 3 for the IP realm associated with the connection address and port information for the media line in the modified initial SDP offer; and

None of the intermediate IMS CN subsystem entities manipulated with the initial SDP offer but the identity of user_B@operator_Y.net in the Request-URI is change to the contact address, i.e. UE-B@operatorX.net.

The intermediate IMS CN subsystem entities select an IBCF, IBCF-3, in the realm "Ya.operatorY.net" and forward the INVITE request with the initial SDP offer to the IBCF-3 according to TS 24.229 [4].

Table A.5.2-4: SIP INVITE request (IBCF-2 to IBCF-3 via intermediate IMS CN subsystem entities)

INVITE SIP: user_B@operator_Y.net; SIP/2.0

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

c=IN IP4 190.1.15.2

m=audio 11324 RTP/AVP 96 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=220

a=ptime:20

a=maxptime:240

b=AS:30

b=RS:0

b=RR:2000

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.1 49170

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111

a=omr-codecs:2 audio RTP/AVP 96 97

a=omr-m-att:2 rtpmap:96

a=omr-m-att:2 telephone-event

a=omr-m-att:2 rtpmap:97 AMR/8000/1

a=omr-m-att:2 fmtp:97

a=omr-m-att:2 mode-change-capability=2; max-red=220; octet-align=1

a=omr-m-att:2 curr:qos local none

a=omr-m-att:2 curr:qos remote none

a=omr-m-att:2 des:qos mandatory local sendrecv

a=omr-m-att:2 des:qos none remote sendrecv

a=omr-m-att:2 ptime:20

a=omr-m-att:2 maxptime:240

a=omr-s-bw:2 AS:30

a=omr-s-bw:2 RS:0

a=omr-s-bw:2 RR:2000

a=visited-realm:3 Ya.operatorY.net IN IP4 190.1.15.2 11324

a=omr-m-cksum:(..)

a=omr-s-cksum:0

6. INVITE request (IBCF-3 to IBCF-4) – see example in table A.5.2-6

The IBCF-3 uses procedures in clauses 6.1.4, 6.1.7 and 6.1.9 since previous MRs can be bypassed and no local MR is needed for realm matching.

The IBCF-3:

– uses the connection address and port information from the selected instance 2 for the media line in the initial SDP offer as incoming connection address and incoming port information for the media line in the subsequent steps. The instance 2 is selected since it contains more codecs than the visited-realm instance 1;

– reconstructs the associated codec information for the media line in the initial SDP offer from the selected instance 2 according to clause 5.3 and uses that codec information as incoming codec information in the subsequent steps;

– deletes visited-realm instance 3;

– insert the incoming codec information into the SDP m-line and associated attribute lines of the modified initial SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded initial SDP offer;

– uses the incoming port information as determined in previous steps as port information in the SDP m-line of the modified initial SDP offer;

– selects an IBCF, IBCF-4, in the realm "Xa.operatorX.net" and forwards the INVITE request with the initial SDP offer according to TS 24.229 [4] to IBCF-4.

Table A.5.2-6: SIP INVITE request (IBCF-3 to IBCF-4)

INVITE SIP: UE-B@operator_Y.net; SIP/2.0

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

c=IN IP4 192.0.2.5

m=audio 62111 RTP/AVP 96 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=220

a=ptime:20

a=maxptime:240

b=AS:30

b=RS:0

b=RR:2000

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.1 49170

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111

a=omr-codecs:audio RTP/AVP 96 97

a=omr-m-att:2 rtpmap:96

a=omr-m-att:2 telephone-event

a=omr-m-att:2 rtpmap:97 AMR/8000/1

a=omr-m-att:2 fmtp:97

a=omr-m-att:2 mode-change-capability=2; max-red=220; octet-align=1

a=omr-m-att:2 curr:qos local none

a=omr-m-att:2 curr:qos remote none

a=omr-m-att:2 des:qos mandatory local sendrecv

a=omr-m-att:2 des:qos none remote sendrecv

a=omr-m-att:2 ptime:20

a=omr-m-att:2 maxptime:240

a=omr-s-bw:2 AS:30

a=omr-s-bw:2 RS:0

a=omr-s-bw:2 RR:2000

a=omr-m-cksum:(..)

a=omr-s-cksum:0

7. INVITE request (IBCF-4 to P-CSCF B) – see example in table A.5.2-7.

The IBCF-4 uses procedures in clauses 6.1.5, 6.1.7 and 6.1.9 since the visited-realm with the highest instance number is connected to the same realm as the IBCF-4 and contains codecs according to the local policy. Using the visited-realm instance 1 would reduce the number of available codecs. No MR for realm matching is needed.

The IBCF-4:

– uses the connection-address from the SDP c-line in the received initial SDP offer as incoming connection-address in subsequent steps;

– uses the port information from the SDP m-line in the received initial SDP offer as incoming port information in subsequent steps;

– uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received initial SDP offer as incoming codec information in the subsequent steps;

– inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified initial SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded initial SDP offer; and

– use the incoming port information as determined in previous steps as port information in the SDP m-line of the modified initial SDP offer; and

– forwards the INVITE request with the unmodified initial SDP offer to the P-CSCF-B according to TS 24.229 [4].

Table A.5.2-7: SIP INVITE request (IBCF-4 to P-CSCF B)

INVITE SIP: UE-B@operator_Y.net; SIP/2.0

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

c=IN IP4 192.0.2.5

m=audio 62111 RTP/AVP 96 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=220

a=ptime:20

a=maxptime:240

b=AS:30

b=RS:0

b=RR:2000

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.1 49170

a=visited-realm:2 Xa.operatorX.net IN IP4 192.0.2.5 62111

a=omr-codecs:2 audio RTP/AVP 96 97

a=omr-m-att:2 rtpmap:96

a=omr-m-att:2 telephone-event

a=omr-m-att:2 rtpmap:97 AMR/8000/1

a=omr-m-att:2 fmtp:97

a=omr-m-att:2 mode-change-capability=2; max-red=220; octet-align=1

a=omr-m-att:2 curr:qos local none

a=omr-m-att:2 curr:qos remote none

a=omr-m-att:2 des:qos mandatory local sendrecv

a=omr-m-att:2 des:qos none remote sendrecv

a=omr-m-att:2 ptime:20

a=omr-m-att:2 maxptime:240

a=omr-s-bw:2 AS:30

a=omr-s-bw:2 RS:0

a=omr-s-bw:2 RR:2000

a=omr-m-cksum:(..)

a=omr-s-cksum:0

8. INVITE request (P-CSCF to UE- B) – see example in table A.5.2-8.

The P-CSCF-B uses the procedures in clauses 6.1.5, 6.1.7 and 6.1.9 since no previous realm instance offers an opportunity to bypass an MR and no local MR for realm matching is needed.

The P-CSCF-B:

– uses the connection-address from the SDP c-line in the received initial SDP offer as incoming connection-address in subsequent steps;

– uses the port information from the SDP m-line in the received initial SDP offer as incoming port information in subsequent steps;

– uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received initial SDP offer as incoming codec information in the subsequent steps;

– inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified initial SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded initial SDP offer;

– use the incoming port information as determined in previous steps as port information in the SDP m-line of the modified initial SDP offer;

– deletes all OMR attributes from the initial SDP offer according to the local policy; and

– forwards the INVITE request with the modified initial SDP offer to the UE-B according to TS 24.229 [4].

Table A.5.2-8: SIP INVITE request (P-CSCF to UE-B)

INVITE SIP: UE-B@operator_Y.net; SIP/2.0

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

c=IN IP4 192.0.2.5

m=audio 62111 RTP/AVP 96 97 98

b=AS:30

b=RS:0

b=RR:2000

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=220

a=ptime:20

a=maxptime:240

9. 183 (Session Progress) response (UE-B to P-CSCF-B) – see example in table A.5.2-9.

The UE accepts the AMR codec and sends a 183 (Session Progress) response to P-CSCF-B with an initial SDP answer selecting the AMR codec and indicating that resources are not yet available according to TS 24.229 [4].

Table A.5.2-9: 183 (Session Progress) response (UE-B to P-CSCF-B)

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 2312345678 IN IP4 192.0.2.1

s=-

c=IN IP4 192.0.2.4

m=audio 16511 RTP/AVP 96 97

b=AS:30

b=RS:0

b=RR:2000

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:96 telephone-event

a=rtpmap: 97 AMR/8000/1

a=fmtp: 97 mode-change-capability=2; max-red=220; octet-align=1

a=ptime:20

a=maxptime:240

10. 183 (Session Progress) response (P-CSCF-B to IBCF-4) – see example in table A.5.2-9

The P-CSCF-B uses the procedures in clauses 6.2.7 and 6.2.9 since the connection address is valid and no primary local MR was allocated when the initial SDP offer was sent.

The P-CSCF-B forwards the 183 (Session Progress) response with the unmodified initial SDP answer to IBCF-4 according to TS 24.229 [4].

11. PRACK request (IBCF-4 to P-CSCF-B) – see example in table A.5.2-11.

The IBCF-4 uses the procedure in clause 6.2.2 to determine that the transcoder allocated by IBCF-1 is not needed any longer and that a PRACK request can be sent to update the IP address according to visited-realm instance 1.

The IBCF-4 uses the procedures in 6.1.4, 6.1.7 and 6.1.9 since the previous MR at IBCF-1 can be bypassed and no local MR is needed for realm matching.

The IBCF-4:

– uses the connection address and port information from the selected visited-realm instance 1 for the media line in the received initial SDP offer (received in the initial INVITE request in step 6) as incoming connection address and incoming port information for the media line in the subsequent steps;

– reconstructs the associated codec information for the media line in the received initial SDP offer from the selected instance 1 as described in clause 5.3, and use the AMR codec and associated attribute lines as incoming codec information in the subsequent steps;

– deletes every OMR attribute for the media line with instance-number value 2 and 3;

– inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified second SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded second SDP offer;

– uses the incoming port information as port information in the SDP m-line of the modified second SDP offer;

– computes checksum values as described in clause 5.6.3 and replaces or add the "omr-s-cksum" and "omr-m-cksum" attributes for the media line; and

– sends the PRACK request with the modified second SDP offer to P-CSCF-B according to TS 24.229 [4].

Table A.5.2-11: SIP PRACK request (IBCF-4 to P-CSCF-B)

UPDATE SIP: UE_B@operator_Y.net; SIP/2.0

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

b=AS:30

b=RS:0

b=RR:2000

c= IN IP4 192.0.2.1

m=audio 49170 RTP/AVP 96 97

a=rtpmap:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=qos local none

a=curr: qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=ptime:20

a=maxptime:240

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.1 49170

a=omr-m-cksum:(..)

a=omr-s-cksum:(..)

12. PRACK request (P-CSCF-B to UE-B) – see example in table A.5.2-12.

The P-CSCF-B uses the procedure in 6.1.5, 6.1.7 and 6.1.9 since there are no MR to bypass and since no local MR is allocated for realm matching.

The P-CSCF-B:

– uses the connection-address from the SDP c-line in the received second SDP offer as incoming connection-address in subsequent steps;

– uses the port information from the SDP m-line in the received second SDP offer as incoming port information in subsequent steps;

– uses the codec information from the SDP m-line and associated non-OMR attribute lines in the received second SDP offer as incoming codec information in the subsequent steps;

– inserts the incoming codec information into the SDP m-line and associated attribute lines of the modified second SDP offer;

– uses the incoming connection address as the connection address in the SDP c-line of the forwarded second SDP offer;

– uses the incoming port information as port information in the SDP m-line of the modified second SDP offer;

– deletes all OMR related attributes from the second SDP offer according to local policy; and

– forwards the PRACK request and the modified second SDP offer to the UE-B according to TS 24.229 [4].

Table A.5.2-12: SIP PRACK request (P-CSCF-B to UE-B)

PRACK SIP: UE_B@operator_Y.net; SIP/2.0

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

b=AS:30

b=RS:0

b=RR:2000

c= IN IP4 192.0.2.1

m=audio 49170 RTP/AVP 96 97

a=rtpmap:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=qos local none

a=curr: qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=ptime:20

a=maxptime:240

13. 200 (OK) response (UE-B to P-CSCF-B) – see the SDP example in table A.5.2-9.

The UE accepts the AMR codec and sends a 200 (OK) response to the PRACK request to P-CSCF-B with a second SDP answer indicating that resources are not yet available according to TS 24.229 [4].

14. 200 (OK) response (P-CSCF-B to IBCF-4) – see the SDP example in table A.5.2-9.

The P-CSCF-B uses the procedures in clauses 6.2.7 and 6.2.9 since the connection address is valid and no primary local MR was allocated when the second SDP offer was sent.

The P-CSCF-B forwards the 200 (OK) response to the PRACK request with the unmodified second SDP answer to IBCF-4 according to TS 24.229 [4].

15. 183 (Session Progress) response (IBCF-4 – to IBCF-3) – see example in table A.5.2-15.

The IBCF-4 continues from the point in step 10 where the 183 (Session Progress) response was received with an initial SDP answer corresponding to the visited-realm 1 and no transcoding by IBCF-1 was required.

The IBCF-4 uses the procedures in clause 6.2.7 and 6.2.9 since a valid connection address was received in the 200 (OK) response to the UPDATE request and no MR was allocated when the initial SDP offer was sent.

The IBCF-4:

– copies into the media line of the initial SDP answer the visited-realm instance 1 from the media line of the received initial SDP offer that was used to populate the connection address and port information in the forwarded second SDP offer, replacing the connection-address and port information in the instance with the connection address and port information from the received second SDP answer;

– replaces the connection address information in the initial SDP answer with the unspecified address of IPv4, "0.0.0.0"; and

– sends the 183 (Session Progress) response with the modified second SDP answer as the initial SDP answer to the IBCF-3 according to TS 24.229 [4].

Table A.5.2-15: 183 (Session Progress) response (IBCF-4 – to 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 2312345678 IN IP4 192.0.2.1

s=-

b=AS:30

b=RS:0

b=RR:2000

c=IN IP4 0.0.0.0

m=audio 16511 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=ptime:20

a=maxptime:240

a=visited-realm:1 Xa.operatorX.net IN IP4 192.0.2.4 16511

16-17. 183 (Session Progress) response (IBCF-3 to IBCF-2 via intermediate IM CN subsystem entities) – see example in table A.5.2-16.

The IBCF-3 uses the procedures in clauses 6.2.5 and 6.2.9 since the initial SDP answer contains an unspecified connection address and a visited-realm instance and the allocated MR is not needed.

The IBCF-3 forwards the 183 (Session Progress) response with the unmodified initial SDP answer to the intermediate IM CN subsystem entities according to TS 24.229 [4].

The intermediate IM CN subsystem entities forwards the 183 (Session Progress) response with the unmodified initial SDP answer to the IBCF-2 according to TS 24.229 [4].

18. 183 (Session Progress) response (IBCF-2 to IBCF-1) – see example in table A.5.2-16.

The IBCF-2 uses procedures in clauses 6.2.5 and 6.2.9 since an unspecified connection address and a visited-realm instance was received and the allocated MR is not needed.

IBCF-2:

– forwards the 183 (Session Progress) response with the unmodified initial SDP answer to IBCF-1 according to TS 24.229 [4]; and

– keeps the allocated MR until it is no longer potentially needed for this and any other forked dialog.

19. 183 (Session Progress) response (IBCF-1 to P-CSCF-A) – see example in table A.5.2-19.

The IBCF-1 uses the procedures in clauses 6.2.5 and 6.2.9 since an unspecified connection address and a visited-realm instance was received and the MR allocated for transcoding is not needed.

– replaces the connection address and port information for the media line in the initial SDP answer with the connection address and port information from the visited-realm instance 1 in the received initial SDP answer;

– forwards the 183 (Session Progress) response with the modified initial SDP answer to P-CSCF-A according to TS 24.229 [4]; and

– keeps the MR allocated for transcoding until it is no longer potentially needed for this and any other forked dialog.

Table A.5.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 2312345678 IN IP4 192.0.2.1

s=-

b=AS:30

b=RS:0

b=RR:2000

c=IN IP4 192.0.2.4

m=audio 16511 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:96 telephone-event

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1

a=ptime:20

a=maxptime:240

20. 183 (Session Progress) response (P-CSCF-A to UE-A) – see example in table A.5.2-23.

The P-CSCF-A uses procedures in clause 6.2.7 and 6.2.9 since a valid connection address is received and no MR was allocated when the initial SDP offer was sent.

P-CSCF-A forwards the 183 (Session Progress) response with the unmodified initial SDP answer to the UE-B according to TS 24.229 [4].

21-74. Remaining SIP message for establishing the call

The rest of the steps follow the same principles as described in clause A.3.2 steps 17 – 65.