14 Roles for addition and deletion of media within collaborative session for inter-UE transfer
24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS
14.1 Introduction
This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when the controller UE or the remote UE adds or releases media to the collaborative session.
14.2 SC UE
14.2.1 Procedures for adding new media on controllee UE by controller UE
The SC UE procedures for adding new media to a controllee UE by the controller UE is the same as the procedure described in subclause 11.2.2.1 with exception that the controller UE additionally sets the port numbers for the media types of the media components (in the "body" URI header field of the SIP URI in the Refer-To header field of the SIP REFER request) which are already served by the controllee UE to values from the corresponding media lines received during the last successful SDP offer and answer exchange with the remote party.
14.2.2 Procedures for releasing media on controllee UE by controller UE
The controller UE may release one or more media components on a controllee UE within a collaborative session while it has an ongoing IMS session with a remote UE.
The controller UE shall release the media by sending a SIP REFER request for releasing media component as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and IETF RFC 7647 [54], including:
1) the Request-URI set to the Inter UE Transfer SCC AS URI;
2) the Refer-To header field as follows:
a) the SIP URI of the controllee UE;
NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the same public user identity.
b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the media type for each of the media (m=) lines in the session shall be set as follows:
– media lines that are not being released with their port numbers; and
– media line(s) that are to be released with the port number set to zero;
c) if the controller UE also wishes to transfer control of the collaborative session to the controller UE then the SIP URI additionally containing the XML body specified for the Refer-To URI in subclause 18.2.1;
3) the Accept header field set to "message/sipfrag";
4) the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of the dialog between the SCC AS and the controller UE;
5) the Contact header field containing:
– the g.3gpp.iut-controller media feature tag as described in annex C; and
– the g.3gpp current-iut-controller media feature tag as described in annex C set to "passive" if the controller UE does not wish to remain the controller of the collaborative session; and
6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to the controllee UE.
The controller UE shall handle SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests according to 3GPP TS 24.229 [7]. The controller UE shall save the media information (e.g. media line number) received in the sipfrag body of the SIP NOTIFY request in order to perform further inter-UE transfer operations on the controllee UE.
14.2.3 Procedures for releasing media on controller UE by controller UE
If the controller UE wants to release a media component on the controller UE within a collaborative session, the controller UE shall follow the procedures defined in 3GPP TS 24.229 [7] for removing media with the following differences:
1. include the SDP information for all other media components within the collaborative session in the SIP re-INVITE request;
2. set all the port numbers of the media on the controllee UEs with value zero; and
3. include the g.3gpp.iut-controller media feature tag as described in annex B in the Contact header field.
14.2.4 Procedures for controller UE to remove a controllee UE from the collaborative session
The controller UE may remove a controllee UE from a collaborative session while it has an ongoing IMS session with a remote UE.
The controller UE shall remove the controllee UE from the collaborative session by sending a SIP REFER request, including:
1) the Request-URI set to the Inter UE Transfer SCC AS URI;
2) the Refer-To header as follows:
a) the SIP URI of the controllee UE;
NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the same public user identity.
b) the method parameter set equal to "BYE";
3) the Accept header field set to include "message/sipfrag";
4) the Target-Dialog header field populated as specified in IETF RFC 4538 [40], containing the dialog identifier of the dialog between the SCC AS and the controller UE; and
5) the Referred-By header field containing a currently registered public user identity of the user to be delivered to the controllee UE; and
6) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B.
The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according to 3GPP TS 24.229 [7].
14.2.5 Procedures for releasing media component by controllee UE
14.2.5.1 Controller UE
When controller UE receives a SIP re-INVITE request, it can contain an SDP offer with:
– media lines for media components already terminated at the controller UE with non-zero port numbers;
– media line(s) for media components terminated at the controllee UE which is releasing the media conponent(s) with non-zero port number(s); and
– media lines for media components terminated at other controllee UEs, with port numbers set to zero.
Upon receiving such a SIP re-INVITE request, the controller UE shall follow the procedures described in 3GPP TS 24.229 [7] to accept or reject the released media component(s) by the controllee UE.
If the released media component(s) is the only media component(s) used within the collaborative session and the controller UE did not accept that media component, the controller UE shall release the collaborative session following the procedures described in 3GPP TS 24.229 [7].
14.2.5.2 Controllee UE
There are no specific procedures for the controllee UE for release of media component by controllee UE, besides the procedures described in 3GPP TS 24.229 [7].
14.2.6 Procedures for modifying media on controllee UE by itself
If the controllee UE wants to modify the characteristics of a media component on itself within a collaborative session, the controllee UE shall follow the procedures defined in 3GPP TS 24.229 [7] for modifying media.
14.2.7 Procedures for adding new media by remote UE when the controller UE does not alert the user
When controller UE receives a SIP re-INVITE request within an existing dialog from the remote UE to add a new media component on the collaborative session, the controller UE shall decide whether adding the new media on itself or adding it to one of its controllee UE.
If the controller UE decides to add the new media component on itself, the controller UE shall follow the precedure as specified in 3GPP TS 24.229 [7],
If the controller UE decides to add the new media component on one of its controllee UE, the controller UE shall send a SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [32] as updated by RFC 6665 [48] and IETF RFC 7647 [54], and include:
1) the Request-URI set to the Inter UE Transfer SCC AS URI;
2) the Refer-To header field, including:
a) the SIP URI of the controllee UE where the media stream should be established from; and
NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the same public user identity.
b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the media type for each of the media (m=) lines in the session shall be set as follows:
– media lines that are not being transferred with the port number set to zero;
– media line(s) that are to be added at the controllee UE the same SDP information as in the SIP re-INVITE request received from the remote UE.
3) the Accept header field containing the MIME types "message/sipfrag";
4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session;
5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex B; and
6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to the controllee UE.
The controller UE shall handle a SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests according to 3GPP TS 24.229 [7]. Then the controller UE shall respond to the SIP re-INVITE request with a SIP 200 (OK) response with a SDP answer as specified in 3GPP TS 24.229 [7] including in the Contact header field the g.3gpp.iut-controller media feature tag as described in annex B, and construct the SDP information in the SIP 200 (OK) response as follows:
1) set the port number of the new added media component with value zero; and
2) set all the ports number of the media on the controllee UEs with value zero; and
3) for other media components on the controller UE are not changed.
If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final response, the controller UE shall consider the transfer operation failed and make a decision again whether adding the new media on itself or adding it on other controllee UE.
14.2.8 Procedures for releasing media by remote UE
Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media components are to be released on the controller UE, the controller UE shall release the media component following the procedures specified in 3GPP TS 24.229 [7].
If the media component to be released is the last media component between the controller UE and the remote party and if there are more media components within the collaborative session, the controller UE shall not release the dialog with the SCC AS but set the port number(s) associated to the media type(s) to zero.
If the media component to be released is the last media component in the collaborative session, the controller UE shall follow the procedures described in subclause 13.2.1.1.
14.3 SCC AS
14.3.0 Distinction of requests at the SCC AS
When SCC AS receives a SIP REFER request within a new dialog from the controller UE with:
1) the Request-URI set to inter UE transfer SCC AS URI;
2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE; and
3) the Refer-To header field set to SIP URI of a controllee UE and containing the URI header field with the hname "body" containing SDP with a media type for each of the media (m=) lines in the session as follows:
– all the media components with associated information in the session; and
– one or more new media components which are not used in the collaborative session yet and with associated port number set to the discard port number "9";
the SCC AS shall follow the procedure in subclause 14.3.1 to add the media component to the controllee UE.
When the SCC AS receives a SIP REFER request in a new dialog from the controller UE with:
1) the Request-URI set to inter UE transfer SCC AS URI; and
2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE;
3) the Refer-To header field containing the SIP URI of a controllee UE and containing the URI header field with the hname a "body" containing SDP with a media type for each of the media (m=) lines in the session as follows :
– all the media components with associated information in the session; and
– the media component which is currently used in the collaborative session by the controllee UE is listed with port number set to 0.
then the SCC AS shall follow the procedure in subclause 14.3.2 to release the media component from the controllee UE.
If a SIP REFER request contains the Contact header field the media feature tag g.3gpp current-iut-controller set to "passive" and the SIP URI in the Refer-To header field contains the XML specified in annex D.3 containing a <controlTransfer> element containing a <targetController> element along with a <requestedBy> element then in the procedures below, such SIP REFER requests are called "SIP REFER requests for transferring control of the collaborative session".
When the SCC AS receives a SIP REFER request in a new dialog from the contoller UE with:
1) the Request-URI set to SIP URI of the SCC AS;
2) the Target-Dialog header field identifies and existing dialog between the SCC AS and the controller UE; and
3) the Refer-To header field containing the SIP URI of a controllee UE and the method parameter set equal to "BYE";
then the SCC AS shall follow the procedure in subclause 14.3.2B to remove the controllee UE.from the collaborative session.
14.3.1 Procedures for adding new media on controllee UE by controller UE
The SCC AS procedures for adding new media on controllee UE by the controller UE is the same as the procedure described in subclause 11.3.3 with exception that upon receipt of SIP REFER request from the controller UE, the SCC AS generates a SIP re-INVITE request within the dialog to the controllee UE instead of SIP INVITE request.
14.3.2 Procedures for releasing media on controllee UE by controller UE
When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header indicating that a SIP INVITE request is to be sent to remove one or more media components on a controllee UE, the SCC AS shall send:
1) a SIP 200 (OK) response to the controller UE;
2) SIP NOTIFY request with a sipfrag including SIP 100 (Trying) to the controller UE;
3) send a SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 3GPP TS 24.229 [7] with the following clarifications:
– if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be released;
– if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be released;
– include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [33] for the media component to be released; and
When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the remote leg the SCC AS continues with the next steps;
NOTE 1: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due to media sent to closed port that could result in the release of the call. The ICMP message is specified in IETF RFC 792 [28].
1) send a SIP re- INVITE request to the controllee UE, containing an SDP offer changed using the media type(s) present in the hname "body" URI header field from the SIP URI in the Refer-To header; and
2) the Referred-By header field containing the values from the Referred-By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36].
NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request.
Upon receiving a SIP 200 (OK) response from the controllee UE, the SCC ASshall send a SIP re-INVITE request to the remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows:
1) set port number for each removed media component to zero; and
2) include the SDP information for all other media components in the collaborative session as from the original session to the remote leg.
Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send:
1) a SIP ACK request to the remote leg;
2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a sipfrag body that shall include the SIP 200 (OK) response of the SIP re-INVITE request and also include the Content-Type header field from the received 200 (OK) response along with the SDP answer received from the controllee UE.
14.3.2A Procedures for releasing media on controller UE by controller UE
When SCC AS receives a SIP re-INVITE request within an existing dialog from the controller UE to remove a media component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows:
1) set port number(s) for each of the removed media component(s) to zero; and
2) include the SDP information for all other media components in the collaborative session as received during the last successful SDP offer-answer exchange from the remote UE.
Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send:
1) a SIP ACK request to the remote UE;
2) a SIP 200 (OK) response to the controller UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP infromation in the SIP 200 (OK) response as follows:
– set port number(s) for each of the removed media component(s) to zero; and
– set all the ports number of the media on the controllee UEs with value zero.
14.3.2B Procedures for controller UE removing controllee UE from the collaborative session
When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header indicating that a SIP BYE request is to be sent to a controllee UE, the SCC AS shall send:
1) SIP 200 (OK) response to the controller UE;
2) SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and
3) SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 3GPP TS 24.229 [7] with the following clarifications:
– if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be released;
– if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be released; and
– include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [33] for the media component to be released.
NOTE: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due to media sent to closed port that could result in the release of the call. The ICMP message is specified in IETF RFC 792 [28].
When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the remote leg the SCC AS shall send a SIP BYE request to the controllee UE to release the controlled session in accordance with 3GPP TS 24.229 [7] including the Referred-By header field containing the values from the Referred-By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36].
Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AS shall send a SIP re-INVITE request to the remote leg as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows:
1) set port number(s) for each removed media component(s) to zero; and
2) include the SDP information for all other media components in the collaborative session as from the original session to the remote leg.
Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send:
1) a SIP ACK request to the remote leg;
2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a sipfrag body that shall include the SIP 200 (OK) response of the SIP BYE request.
14.3.3 Procedures for releasing media component initiated by controllee UE
When the SCC AS receives a SIP re-INVITE request from a controllee UE containing an SDP offer with one or more media line(s) used on the controllee UE with port number set to zero, where the port number was previously not zero, the SCC AS shall send a SIP re-INVITE request towards the controller UE containing an SDP offer with the following details:
1) for the media lines on the controller UE, set the port numbers to the values received during the last successful SDP offer and answer exchange with the remote party;
2) for the media lines on the controllee UE which were offered with port numbers set to zero in the SDP offer received in the re-INVITE from the controllee UE, set the port numbers to the values received during the last successful SDP offer and answer exchange with the remote party; and
3) set the port number to zero for the remaining media lines.
When the SCC AS receives a SIP BYE request from a controllee UE, the SCC AS shall send a SIP re-INVITE request towards the controller UE containing an SDP offer with the following details:
1) for the media lines on the controller UE, set the port numbers to the values received during the last successful SDP offer and answer exchange with the remote party;
2) for the media lines on the controllee UE, set the port numbers to the values received during the last successful SDP offer and answer exchange with the remote party; and
3) set the port number to zero for the remaining media lines.
Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request from the controller UE and in addition to the procedures of 3GPP TS 24.229 [7], the SCC AS shall send a SIP re-INVITE request towards the remote party containing an SDP offer with:
1) all the media lines which were not released by the controllee UE including their port numbers; and
2) all the media lines which were released by the controllee UE set to the port numbers received in the SDP answer contained in the SIP 200 (OK) response from the controller UE.
Upon receiving the SIP 200 (OK) response from the remote party, and in additon to the procedures of 3GPP TS 24.229 [7], the SCC AS shall:
1) if the transaction was initiated by a SIP re-INVITE request, send a SIP 200 (OK) response for the SIP re-INVITE request towards the controllee UE containing an SDP answer accepting the SDP offer from the controllee UE; or
2) if the transaction was initiated by a SIP BYE request, send a SIP 200 (OK) response for the SIP BYE request towards the controllee UE.
14.3.4 Procedures for modifying media on controllee UE by itself
When SCC AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows:
1) set the modified media information as the same in the SIP re-INVITE request received from the controllee UE; and
2) include the SDP information for all other media components in the collaborative session as received during the last successful SDP offer-answer exchange from the remote UE.
Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send:
1) a SIP ACK request to the remote UE; and
2) a SIP 200 (OK) response to the controllee UE with an SDP answer that only contains the media component on the controllee UE.
14.3.5 Procedures for adding new media by remote UE when the controller UE does not alert the user
When SCC AS receives a SIP REFER request from the controller UE to add a new media component on a controllee UE, the SCC AS shall send:
1) SIP 200 (OK) response
2) SIP NOTIFY request containing a sipfig for a SIP 100 (Trying) response to the controller UE as described in IETF RFC 3515 [32] as updated by RFC 6665 [48];
3) if the target controllee UE has not been involved in the collaborative session, send a initial SIP INVITE request to the controllee UE to add the controlee UE in the collaborative session, containing:
a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request;
b) the Referred-By header field containing the values from the Referred-By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36];
c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted-Identity header field from SIP re-INVITE request received from the remote UE; and
d) the SDP information for the media component to be transferred as follows:
– The media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in the Refer-To header field of the received SIP REFER request; and
– for media lines which have non zero port numbers the SDP parameters from the corresponding media lines as received in the SDP offer from the remote UE in the SIP re-INVITE request.
4) if there are other media component within the collaborative session between the target controllee UE and the remote UE, send a SIP re-INVITE request to the controllee UE, containing:
a) the Referred-By header field containing the values from the Referred-By header field of the received SIP REFER request according to the procedures of IETF RFC 3892 [36];
b) the SDP information for the media component to be transferred as follows:
– The media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in the Refer-To header field of the received SIP REFER request; and
– for media lines which have non zero port numbers, the SDP parameters from the corresponding media lines as received in the SDP offer from the remote UE in the SIP re-INVITE request
– for other media components that have already involved in the collabartive session are not changed.
Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing the received response code in the sipfrag body and if the received SIP response was a SIP 200 (OK) response containing an SDP answer then also include in the sipfrag the Content-Type header field from the received SIP 200 (OK) response along with the media (m=) lines from the SDP answer.
If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort the media transfer.
If the SIP final response was a SIP 200 (OK) response containing a SDP answer, the SCC AS shall:
1) send a SIP ACK request to the controllee UE;
2) send a SIP 200 (OK) response to the remote UE as specified in 3GPP TS 24.229 [7]. The SCC AS shall construct the SDP infromation in the SIP 200 (OK) response as follows:
– set the same SDP information for the new added media as in the SIP 200 (OK) response received from the controlee UE; and
– include the SDP information for all other media in the collaborative session as received during the last successful SDP offer-answer exchange from the remote UE.
14.3.6 Procedures for releasing media by remote UE
Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media components to be released on the controller UE, the SCC AS shall set the port number on the media line(s) which are not on controller UE to zero and forward the SIP re-INVITE request towards the controller UE following the procedures as specified in 3GPP TS 24.229 [7].
Upon receipt from the remote party of a SIP re-INVITE request containing an SDP offer indicating one or more media components to be released on the controllee UE, the SCC AS shall:
– if there are more media components left after releasing the selected media components, set the port number(s) on the media line(s) which are not on the controllee UE to zero and forward the SIP re-INVITE request; or
– if there are no more media components left after releasing the selected media components, send a SIP BYE request;
towards the controllee UE following the procedures as specified in 3GPP TS 24.229 [7].
Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media components to be released on the controller UE and one or more media components to be released on the controllee UE(s), the SCC AS shall:
– send a SIP re-INVITE request to the controller UE containing the SDP received from the remote end with the exception that the port numbers of the media components, not terminated on the controller UE, are set to zero;
– if not all the media component(s) are being released on the controllee UE, send a SIP re-INVITE request to that controllee UE, containing the SDP received from the remote end with the exception that the port numbers of the media components, not terminated on the controllee UE, are set to zero; and
– if all the media component(s) are being released on the controllee UE, send a SIP BYE request to the controllee UE.