D.1 General

24.5283GPPCommon Basic Communication proceduresProtocol specificationRelease 8TISPANTS

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 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 value.

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.

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 RFC 3261 [4].

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

The following signalling flows provide examples for the 3pcc procedures described in clause 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):
Bibliography

  • ETSI TS 123 218: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia (IM) session handling; IM call model; Stage 2 (3GPP TS 23.218)".
  • ETSI TS 181 002: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Multimedia Telephony with PSTN/ISDN simulation services".
  • IETF RFC 2234: "Augmented BNF for Syntax Specifications: ABNF".
  • ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description
    (3GPP TS 23.228 v7.2.0, modified)".
  • IETF RFC 4566: "SDP: Session Description Protocol".

Annex G (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2008-01

Publication as ETSI TS 183 028

2.4.0

2008-01

Conversion to 3GPP TS 24.528

2.4.1

2008-03

CT#39

CP-080099

Based on the decision in CT#39 version 8.0.0 created by MCC.

2.4.1

8.0.0

2008-06

CT#40

CP-080350

0001

1

Alert-Info instead of Call-Info

8.0.0

8.1.0

2008-09

CT#41

CP-080521

0002

1

Deletion of unnecessary usage of announcement

8.1.0

8.2.0

2012-12

CT#58

CP-120778

0003

2

Communication rejection announcement correction

8.2.0

8.3.0