D.1 General

24.6283GPPCommon Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS

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

If the AS needs to establish an early dialog between itself and the originating UE (or originating network), for example in order to establish a media path in order to send announcements or other kind of early media backwards, it shall do so by sending a provisional response including a P-Early-Media header field containing either the "sendrecv" or the "sendonly" towards the originating UE. The setup procedures between the originating UE and the AS are identical to normal setup procedures.

The To header tag value in the dialog between the originating UE and the AS shall, in order to separate the dialogs, be different than the To header tag value in messages used on the dialog used between the originating and terminating UEs. The AS normally receives the To header tag value for the dialog between the UEs from the terminating UE (or the terminating network), but if the AS acts as a B2BUA it may also, depending on the functionality, generate a new To header tag value.

If the AS controls early media and has sent a P-Early-Media header field with either a value "sendonly" or a value "sendrecv", the AS shall ensure during the media transmission that no P-Early-Media header field sent on any other dialog contains the value "sendrecv" or "sendonly".

If the AS updates media characteristics, the AS may send an UPDATE message including an SDP offer and a P-Early-Media header field with an intended media flow direction.

To terminate the announcement the AS can send a new SDP offer including "a=inactive", or terminate the early dialog using the 199 (Early Dialog Terminated) provisional response if the originating UE has indicated support of the 199 (Early Dialog Terminated) response code [18].

If the AS needs to establish an early dialog between itself and the originating UE triggered by the receipt of a provisional responses of the terminating UE, and the terminating UE has already included a SDP answer in a reliable provisional response, the AS first shall forward the provisional response to the originating UE reliably in the e2e dialog, after changing the Status-Line to SIP 183 (Session Progress) response.

The need for the AS to establish an early dialog between itself and the originating UE is determined on the services offered to the originating UE.

If the AS wants to terminate the early dialog between itself and the originating UE before the terminating UE has sent a final SIP response, and the originating UE has indicated support of the 199 (Early Dialog Terminated) response code [18], the AS shall send a 199 (Early Dialog Terminated) provisional response towards the originating UE.

NOTE 1: Unless the originating UE can determine that the messages sent on the early dialog between itself and the AS are originated from the AS, it will assume that forking has occurred in the network.

NOTE 2: If the originating UE has indicated that it does not want the initial INVITE to be forked, the AS may still establish a separate early dialog between itself and the originating UE, since even though the originating UE may assume that the call has been forked only one terminating UE will actually receive the INVITE request.

NOTE 3: Once the originating UE has received 200 (OK) from the terminating UE the early dialog between the originating UE and the AS will be terminated, as described in IETF RFC 3261 [4].

Annex E (informative):
Signalling flows for 3^rd party call control

The following signalling flows provide examples for the 3pcc procedures described in subclause 4.7.2.9.7.

Figure E.1: Example flow for REFER interworking with REFER sent
inside a dialog with usage of a media server

Figure E.2: Example flow for REFER interworking with REFER sent
outside a dialog with usage of a media server

Figure E.3: Example flow for REFER interworking in case of
No Reply with usage of a media server

Figure E.4: Example flow for REFER interworking in case the Refer-to header field
contains a replaces parameter with usage of a media server

Figure E.5: Example flow for REFER interworking with REFER sent inside a dialog
without usage of a media server

Annex F (informative):
Void

Annex G (normative):
AS actions using gateway model