A.9 Signalling flows for media adding/deleting for access transfer
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
A.9.1 Introduction
The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. The following signalling flow is included:
– subclause A.9.2 shows an example when the non-realtime media of a multimedia session over the IP-CAN is removed.
A.9.2 Remote End Initiation case – Removing media from split CS and PS sessions
As a precondition the SC UE A has a CS call and IMS multimedia session with the remote UE after session transfer in a manner that more than one session are presented to UE B as one IMS session by the SCC AS.
Figure A.9.2-1: Remote End Initiation case – Removing media from split CS and PS sessions
NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.
1. SC UE A has an ongoing multimedia session with remote UE B
The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A.
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B.
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example.
Table A.9.2-1: SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)
INVITE tel:+1-237-555-2222 SIP/2.0
Via:
Max-Forwards:
Route:
P-Asserted-Identity:
P-Charging-Vector:
P-Access-Network-Info:
Privacy:
From:
To:
Call-ID:
Cseq:
Supported:
Require:
Proxy-Require:
Security-Verify:
Contact:
Allow:
Accept:
Content-Type:
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=message 7654 TCP/MSRP 98
a=accept-types:text/plain
2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2
The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS procedures to remove one or more PS media from the session.
Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)
INVITE < sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> SIP/2.0
Via: SIP/2.0/UDP sccas1.home1.net;branch=z9hG4bKnas34r5
Max-Forwards: 67
Route: <sip:scscf1.home1.net:lr>
P-Asserted-Identity: <tel: +1-237-555-2222>
P-Charging-Function-Addresses: ####
P-Charging-Vector: ####
P-Access-Network-Info:
Privacy: none
From: <tel: +1-237-555-2222; gr=hdg7777ad7aflzig8sf7>;tag=171828
To: <tel:+1-237-555-1111>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel, precondition
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port=7531
Contact: < sip:user2_public1@home2.net;gr=urn:uuid:2ad8950e-48a5-4a74-8d99-ad76cc7fc74>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Accept: application/sdp, application/3gpp-ims+xml
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
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
m=message 0 TCP/MSRP 98
a=accept-types:text/plain
3. SIP re–INVITE request (Intermediate IM CN subsystem entities to SCC AS)
4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities)
The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote UE B.
6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities)
The UE B generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS.
8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities)
The SCC AS terminates the replaced call leg, which was using the IP-CAN, by sending a SIP BYE request to the UE A.
10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities)
Upon receiving the SIP BYE request over the IP-CAN, the SC UE A sends a SIP 200 (OK) response over the IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP-CAN.
12. Media paths between SC UE A and UE B
Finally, the non-realtime media path over the IP-CAN is removed.