MMD Supplementary Services - 3GPP2 · MMD Supplementary Services X.S0055-0 v1.0 1 2 3 4 5 6 7 8 9...
107
3GPP2 X.S0055-0 Version 1.0 Date: May 2008 MMD Supplementary Services COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
Transcript of MMD Supplementary Services - 3GPP2 · MMD Supplementary Services X.S0055-0 v1.0 1 2 3 4 5 6 7 8 9...
3GPP2 X.S0055-0 Version 1.0 Date: May 2008
MMD Supplementary Services
COPYRIGHT 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
Revision History
Revision Date Rev. 0 v1.0 Initial publication May 2008
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
i Contents
MMD Supplementary Services
CONTENTS 1 Scope........................................................................................................................................................1
2 References................................................................................................................................................2 2.1 Normative References................................................................................................................2
3 Acronyms and Definitions .......................................................................................................................4 3.1 Acronyms...................................................................................................................................4
4 Overview of Supplementary Services ......................................................................................................5 4.1 Introduction................................................................................................................................5 4.2 General Assumptions .................................................................................................................5
5 Functional Entities ...................................................................................................................................7 5.1 Introduction................................................................................................................................7 5.2 User Equipment (UE) ................................................................................................................7 5.3 Application Server (AS) ............................................................................................................7 5.4 Media Resource Function Controller (MRFC) ..........................................................................7
6 Call Hold ..................................................................................................................................................8 6.1 Service Description....................................................................................................................8 6.2 Call Flows..................................................................................................................................8
6.2.1 Call hold without announcement from Network .........................................................9 6.2.2 Call hold with announcement ....................................................................................10 6.2.3 Resume from call hold...............................................................................................12
6.3 Service Procedures for Call Hold.............................................................................................13 6.3.1 UE..............................................................................................................................13 6.3.2 AS..............................................................................................................................13
7 Call Waiting ...........................................................................................................................................15 7.1 Service Description..................................................................................................................15 7.2 Call Flows................................................................................................................................15 7.3 Service Procedures for Call Waiting........................................................................................17
7.3.1 UE..............................................................................................................................17 7.3.2 AS..............................................................................................................................17
8 Call Transfer ..........................................................................................................................................18 8.1 Service Description..................................................................................................................18 8.2 Call Flows................................................................................................................................18
8.2.1 Blind Call Transfer without 3PCC ............................................................................19 8.2.2 Consultative Call Transfer without 3PCC .................................................................21 8.2.3 Blind Call Transfer with 3PCC..................................................................................22 8.2.4 Consultative Call Transfer with 3PCC ......................................................................25
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Contents ii
8.3 Service Procedures for Call Transfer .......................................................................................26 8.3.1 UE..............................................................................................................................26 8.3.2 AS ..............................................................................................................................27
9 Call Forwarding......................................................................................................................................31 9.1 Service Description ..................................................................................................................31 9.2 Call Flows ................................................................................................................................31
9.2.1 Call forwarding unconditional ...................................................................................32 9.2.2 Call forwarding on busy ............................................................................................34 9.2.3 Call forwarding on no-answer ...................................................................................36
9.3 Service Procedures for Call Forwarding ..................................................................................37 9.3.1 UE..............................................................................................................................37 9.3.2 AS ..............................................................................................................................37
10 Caller ID Presentation/Restriction..........................................................................................................43 10.1 Service Description ..................................................................................................................43 10.2 Call Flows ................................................................................................................................44
10.2.1 Caller ID Presentation................................................................................................44 10.2.2 Caller ID Restriction..................................................................................................45
10.3 Service Procedures for CIP/CIR ..............................................................................................46 10.3.1 UE 46 10.3.2 AS 47
11 Terminating ID Presentation/Restriction................................................................................................49 11.1 Service Description ..................................................................................................................49 11.2 Call Flows ................................................................................................................................50
11.2.1 Terminating ID Presentation......................................................................................50 11.2.2 Terminating ID Restriction........................................................................................51
11.3 Service Procedures for TIP/TIR...............................................................................................52 11.3.1 UE 52 11.3.2 AS 52
12 Three-Way Conferencing .......................................................................................................................54 12.1 Service Description ..................................................................................................................54 12.2 Call Flows ................................................................................................................................54
12.2.1 3WC without 3PCC ...................................................................................................54 12.2.2 3WC with 3PCC ........................................................................................................57
12.3 Service Procedures for 3WC....................................................................................................59 12.3.1 UE 59 12.3.2 AS 59
13 Message Waiting Indication...................................................................................................................61 13.1 Service Description ..................................................................................................................61 13.2 Call Flows ................................................................................................................................61
13.2.1 MWI with message-summary event package ............................................................61 13.2.2 MWI with SMS..........................................................................................................62
13.3 Service Procedures for MWI....................................................................................................62
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
iii Contents
13.3.1 UE 62 13.3.2 AS 63
14 DTMF Support .......................................................................................................................................64 14.1 Service Description..................................................................................................................64 14.2 Call Flows................................................................................................................................64 14.3 Service Procedures for DTMF .................................................................................................64
14.3.1 UE 64 14.3.2 AS 64
15 User Provisioning...................................................................................................................................65 15.1 Service Description..................................................................................................................65 15.2 Call Flows................................................................................................................................65
15.2.1 User provisioning using DTMF.................................................................................65 15.2.2 User provisioning using feature code ........................................................................66
15.3 Service Procedures for user provisioning using feature code ..................................................66 15.3.1 UE 66 15.3.2 AS 67
15.4 Service Procedures for user provisioning using DTMF...........................................................67 15.4.1 UE 67 15.4.2 AS 67
16 Customized Ring Back Tones ................................................................................................................68 16.1 Service Description..................................................................................................................68 16.2 Call Flows................................................................................................................................68
16.2.1 Early-session case......................................................................................................69 16.2.2 Non Early-session case..............................................................................................72
16.3 Service Procedures for CRBT..................................................................................................73 16.3.1 UE 73 16.3.2 AS 74
17 Directory Assistance ..............................................................................................................................78 17.1 Service Description..................................................................................................................78 17.2 Call Flows................................................................................................................................78 17.3 Service Procedures for DA ......................................................................................................78
17.3.1 UE 78 17.3.2 AS 79
18 Voice Mail Deposit/Retrieval.................................................................................................................80 18.1 Service Description..................................................................................................................80 18.2 Call Flows................................................................................................................................81
18.2.1 Voice mail deposit .....................................................................................................81 18.2.2 Voice mail retrieval ...................................................................................................82
18.3 Service Procedures for VMD and VMR ..................................................................................83 18.3.1 UE 83 18.3.2 AS 83
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
List of Figures iv
19 Flexible Alerting ....................................................................................................................................84 19.1 Service Description ..................................................................................................................84 19.2 Call Flows ................................................................................................................................85
19.2.1 Flexible Alerting........................................................................................................85 19.2.2 Single User (No Redirection) ....................................................................................87 19.2.3 Multiple User (No Redirection) .................................................................................89
19.3 Service Procedures for Flexible Alerting .................................................................................90 19.3.1 UE 90 19.3.2 AS 90
20 Outbound/Inbound Call Restrictions......................................................................................................92 20.1 Service Description ..................................................................................................................92 20.2 Call Flows ................................................................................................................................92
20.2.1 Outbound Call Restriction .........................................................................................92 20.2.2 Inbound Call Restriction............................................................................................93 20.2.3 Anonymous Call Rejection........................................................................................94
20.3 Service Procedures for OCR/ICR/ACR ...................................................................................94 20.3.1 UE 94 20.3.2 AS 94
21 Short Code Dialing.................................................................................................................................96 21.1 Service Description ..................................................................................................................96 21.2 Call Flows ................................................................................................................................96 21.3 Service Procedures for Short Code Dialing .............................................................................97
21.3.1 UE 97 21.3.2 AS 97
22 Abbreviated Dialing ...............................................................................................................................98 22.1 Service Description ..................................................................................................................98 22.2 Call Flows ................................................................................................................................98 22.3 Service Procedures for Abbreviated Dialing............................................................................99
22.3.1 UE 99 22.3.2 AS 99
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
v List of Figures
LIST OF FIGURES Figure 1 Hold without announcement from the network ..................................................................9 Figure 2 Hold with announcement ..................................................................................................10 Figure 3 Resume from call hold......................................................................................................12 Figure 4 Call Waiting......................................................................................................................16 Figure 5 Blind Call Transfer ...........................................................................................................19 Figure 6 Consultative Call Transfer ................................................................................................21 Figure 7 Blind Call Transfer with 3PCC (18x Offer)......................................................................23 Figure 8 Consultative Transfer with 3PCC .....................................................................................25 Figure 9 Call Forwarding Unconditional ........................................................................................32 Figure 10 Call forwarding on busy ...................................................................................................34 Figure 11 Call forwarding on no-answer ..........................................................................................36 Figure 12 Caller ID Presentation.......................................................................................................44 Figure 13 Caller ID Restriction.........................................................................................................45 Figure 14 Terminating ID Presentation (No Subscription) ...............................................................50 Figure 15 Terminating ID Restriction...............................................................................................51 Figure 16 Three-way conferencing ...................................................................................................55 Figure 17 3WC with 3PCC ...............................................................................................................57 Figure 18 MWI with message-summary event package ...................................................................61 Figure 19 MWI with encapsulated SMS...........................................................................................62 Figure 20 User provisioning with DTMF .........................................................................................65 Figure 21 User provisioning using feature code ...............................................................................66 Figure 22 CRBT Call Flow...............................................................................................................71 Figure 23 CRBT Call Flow...............................................................................................................72 Figure 24 Directory Assistance.........................................................................................................78 Figure 25 Voicemail Deposit ............................................................................................................81 Figure 26 Voice mail retrieval ..........................................................................................................82 Figure 27 Flexible Alerting...............................................................................................................86 Figure 28 Single User (No Redirection) ...........................................................................................87 Figure 29 Multiple User (No Redirection) ........................................................................................89 Figure 30 Outbound Call Restriction ................................................................................................92 Figure 31 Inbound Call Restriction...................................................................................................93 Figure 32 Anonymous Call Rejection...............................................................................................94 Figure 33 Short Code Dialing ...........................................................................................................96 Figure 34 Abbreviated Dialing..........................................................................................................98
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Foreword vi
FOREWORD (This foreword is not part of this Standard.)
“Shall” and “shall not” identify requirements to be followed strictly to conform to this document and from which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is recommended as particularly suitable, without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action permissible within the limits of the document. “Can” and “cannot” are used for statements of possibility and capability, whether material, physical or causal.
REVISION HISTORY
Revision Date Changes
0 v1.0 May 2008 Initial publication
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
2.1 Normative References 1 1 Scope
1 Scope The present document provides the protocol details and example call flows for providing supplementary service to mobile users connected to Multimedia Domain (MMD) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).
The present document is applicable to User Equipment (UEs), Application Servers (AS), Media Resource Function Controller (MRFC), and Media Resource Function Processor (MRFP). The function split between the AS and the MRFC is out of scope of this document. As a result, the procedures for the MRFC are described together with those for the AS.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
2 References 2 2.1 Normative References
2 References
2.1 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid national standards published by them.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2 document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[MMD Part-4] 3GPP2: X.S0013-004, IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3;
[MMD Part-9] 3GPP2: X.S0013-009, IMS/MMD Call Flow Examples;
[RFC2833] IETF: RFC2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
[RFC3261] IETF: RFC3261, SIP: Session Initiation Protocol;
[RFC3262] IETF: RFC3262, Reliability of Provisional Responses in the Session Initiation Protocol (SIP);
[RFC3264] IETF: RFC3264, An Offer/Answer Model with the Session Description Protocol (SDP);
[RFC3265] IETF: RFC3265, Session Initiation Protocol (SIP)-Specific Event Notification;
[RFC3323] IETF: RFC3323, A Privacy Mechanism for the Session Initiation Protocol (SIP);
[RFC3325] IETF: RFC3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks;
[RFC3428] IETF: RFC3428, Session Initiation Protocol (SIP) Extension for Instant Messaging;
[RFC3842] IETF: RFC3842, A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP);
[RFC3891] IETF RFC 3891: "The Session Initiation Protocol (SIP) Replaces header";
[RFC3959] IETF: RFC3959, The Early Session Disposition Type for the Session Initiation Protocol (SIP);
[RFC3966] IETF: RFC3966, The tel URI for Telephone Numbers;
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
2.1 Normative References 3 2 References
[RFC4244] IETF: RFC4244, An Extension to the Session Initiation Protocol (SIP) for Request History Information;
[RFC4458] IETF: RFC4458, Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR);
[RFC5079] IETF: RFC5079, Rejecting Anonymous Requests in the Session Initiation Protocol (SIP);
[X.S0029] 3GPP2 X.S0029: “Conferencing using the IP Multimedia (IM) Core Network (CN) Subsystem; Stage-3”.
[X.S0048] 3GPP2 X.S0048-0: “Short Message Service over IMS”.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
3 Acronyms and Definitions 4 3.1 Acronyms
3 Acronyms and Definitions This section contains definitions, symbols and abbreviations that are used throughout the document.
3.1 Acronyms 3PCC 3rd-Party Call Control 3WC Three-Way Conferencing ACR Anonymous Call Restriction AS Application Server CFB Call Forwarding Busy CFD Call Forwarding Default CFNA Call Forwarding on No Answer CFU Call Forwarding Unconditional CIP Caller Identity Presentation CIR Caller Identity Restriction CRBT Customized Ring Back Tone CSCF Call Session Control Function CT Call Transfer DA Directory Assistance DTMF Dual Tone Multiple Frequency FA Flexible Alerting ICR Inbound Call Restriction I-CSCF Interrogating CSCF IMS IP Multimedia Subsystem IP Internet Protocol MMD Multimedia Domain MGW Media Gateway MRFC Multimedia Resource Function Controller MRFP Multimedia Resource Function Processor MWI Message Waiting Indication OCR Outbound Call Restriction P-CSCF Proxy-CSCF RTP Real-time Transport Protocol SIP Session Initiation Protocol S-CSCF Serving-CSCF SDP Session Description Protocol TIP Terminating Identity Presentation TIR Terminating Identity Restriction UE User Equipment VMD Voice Mail Deposit VMR Voice Mail Retrieval
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
4.1 Introduction 5 4 Overview of Supplementary Services
4 Overview of Supplementary Services
4.1 Introduction The following supplementary services are specified within this document:
Call Hold
Call Waiting
Call Transfer
Call Forwarding (Unconditional, on Busy, on No Answer, Default)
Caller ID Presentation / Caller-ID restriction
Terminating Party ID Presentation / Terminating Party ID Restriction
3-Way Conferencing
Message Waiting Indication
DTMF Support
User Provisioning / Feature Activation /Feature Deactivation
Ring Back Tones
Directory Assistance (411) Services
Voice Mail Deposit (VMD) / Voice Mail Retrieval (VMR)
Flexible Alerting (FA)
Outbound Call Restrictions / Inbound Call Restrictions / Dialling Permissions
Short Code Dialling
Abbreviated Dialling
4.2 General Assumptions All the call flows in this document assume the following:
Although not shown in the call flows, it is assumed that S-CSCF has proper triggers (e.g., initial filter criteria) setup for the user so that initial request for a dialog (e.g. INVITE) or request for a stand-alone transaction are forwarded to the appropriate AS(s) for service execution.
Bold arrows are used to show the media interactions between endpoints. The majority of the call flows are showing the media stream after ACK message. However, it should be noted that the media stream may start any time after successful Offer/Answer exchange between the endpoints.
UE-1 is the UE whose owner (the subscriber) subscribes to the related services. It is assumed that UE-1 is in its home network. Network entities such as P-CSCF, S-
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
4 Overview of Supplementary Services 6 4.2 General Assumptions
CSCF, AS, and MGW are shown in the call flows; but it should be noted that it is possible that other network entities (e.g., I-CSCF) may also be involved in the communication.
Unless otherwise indicated, UE-2 and UE-3 are used to represent the other end points that communicate with UE-1; they may or may not be in the same network as UE-1. None of the network entities associated with UE-2 and UE-3 are shown in the call flows (Captured by dashed line under UE-2 and UE-3).
All the call flows in this document follow the procedures described in [MMD Part-4].
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
5.1 Introduction 7 5 Functional Entities
5 Functional Entities
5.1 Introduction This clause associates the functional entities described for the MMD domain with the roles in supplementary services.
5.2 User Equipment (UE) In addition to the procedures specified in this specification, the UE shall support the procedures specified in [MMD Part-4].
5.3 Application Server (AS) In addition to the procedures specified in this specification, the AS shall support the procedures specified in [MMD Part-4].
5.4 Media Resource Function Controller (MRFC) In order to support some of the services, the MRFC has to provide control of the media between the UE and the MRFP. The functional split between the MRFC and the AS is outside the scope of this document. The procedures for the MRFC are described together with those for the AS.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6 Call Hold 8 6.1 Service Description
6 Call Hold
6.1 Service Description Call hold service allows a user to suspend the media stream(s) of an established IP multimedia session, and resume the media stream(s) at a later time.
6.2 Call Flows This section provides the signaling flows for the following scenarios:
Call Hold without announcement from the network
Call Hold with announcement
Resume Call Hold
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6.2 Call Flows 9 6 Call Hold
6.2.1 Call hold without announcement from Network
1. INVITE (sendonly)
UE-1 P-CSCF S-CSCF AS UE-2
RTP Media between UE-1 and UE-2
2. INVITE (sendonly)
5. INVITE (sendonly)
3. INVITE (sendonly)
6. INVITE (sendonly)
4. No announcement will be played
7. 200 OK (recvonly)
8. 200 OK (recvonly)
9. 200 OK (recvonly)10. 200 OK (recvonly)
11. 200 OK (recvonly)
12. ACK13. ACK
14. ACK
15. ACK
16. ACK
RTP Media from UE-1 to UE-2 (optional)
Figure 1 Hold without announcement from the network
UE-1 and UE-2 are on an active session. UE-1 then decides to put UE-2 on hold.
1~3. UE-1 sends re-INVITE with an SDP offer to put UE-2 on hold. The hold operation is achieved by setting the “a=sendonly” attribute for the media streams. The INVITE is forwarded to the AS by the S-CSCF because the AS was initially included in the signaling path during the original session setup between UE-1 and UE-2.
4. The AS determines that no announcement is played to UE-2 during call hold.
5~6. The AS forwards the re-INVITE to UE-2.
7~11. UE-2 sends 200 OK to acknowledge the re-INVITE.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6 Call Hold 10 6.2 Call Flows
12~16. UE-1 acknowledges with ACK message. The call is now on hold with no announcement from the network to UE-2. UE-1 can optionally play hold music or announcement to UE-2.
6.2.2 Call hold with announcement
Figure 2 Hold with announcement
UE-1 and UE-2 are on an active session. UE-1 then decides to put UE-2 on hold.
1~3. UE-1 sends re-INVITE with an SDP offer to put UE-2 on hold. The hold operation is achieved by setting the “a=sendonly” attribute for the media streams. The INVITE is forwarded to the AS by the S-CSCF because the AS was initially included in the signaling path during the original session setup between UE-1 and UE-2.
4. The AS determines that it needs to play announcement to UE-2 during call hold. It coordinates with MRFP to obtain media resources for playing announcement.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6.2 Call Flows 11 6 Call Hold
5~6. The AS forwards the re-INVITE to UE-2. The INVITE now contains modified SDP offer with MRFP’s information.
7~8. UE-2 sends 200 OK to acknowledge the re-INVITE and includes an SDP answer with “a=recvonly” attribute set for the held media streams.
9. The AS coordinates with MRFP to start announcement.
10~12. The AS forwards 200 OK back to UE-1 to acknowledge the INVITE. The AS may change the direction attribution from “a=recvonly” to “a=inactive” in order to explicitly prohibit UE-1 from sending media.
13~16. UE-1 acknowledges with ACK message. The call is now on hold with announcement from the MRFP to UE-2.
Note: UE-1 relies on operator configuration to decide that it cannot play announcement or music. For the terminating side, if UE-2 receives RTP streams from multiple sources after the session is set up, it should play the RTP stream corresponding to the one indicated by the latest successful offer/answer exchange.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6 Call Hold 12 6.2 Call Flows
6.2.3 Resume from call hold
1. INVITE (sendrecv)
UE-1 P-CSCF S-CSCF AS UE-2
RTP Media between UE-1 and UE-2
2. INVITE (sendrecv)
5. INVITE (sendrecv)
3. INVITE (sendrecv)
6. INVITE (sendrecv)
7. 200 OK (sendrecv)
8. 200 OK (sendrecv)
9. 200 OK (sendrecv)10. 200 OK (sendrecv)11. 200 OK
(sendrecv)
12. ACK13. ACK
14. ACK
15. ACK
16. ACK
MRFP
4. Stop annoucement if playing
Figure 3 Resume from call hold
UE-1 has put UE-2 on hold and now decides to resume the session with UE-2.
1~3. UE-1 sends re-INVITE with an SDP offer to resume the session with UE-2. The resume operation is achieved by setting the “a=sendrecv” attribute for the media streams. The INVITE is forwarded to the AS by the S-CSCF because the AS was initially included in the signaling path during the original session setup between UE-1 and UE-2.
4. The AS stops any announcement that the network is playing toward UE-2 during call hold and releases any MRFP resources if used for announcement.
5~6. The AS forwards the re-INVITE to UE-2.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6.3 Service Procedures for Call Hold 13 6 Call Hold
7~11. UE-2 sends 200 OK to acknowledge the re-INVITE and includes an SDP answer with “a=sendrecv” attribute set for the resumed media streams.
12~16. UE-1 acknowledges with ACK message. The call is now resumed with RTP media exchanged between UE-1 and UE-2.
6.3 Service Procedures for Call Hold
6.3.1 UE
In addition to the application of basic call procedures according to [MMD Part-4], the following procedures shall be applied at the invoking UE in accordance with [RFC3264].
If individual media streams are affected:
for each media stream that shall be held, the invoking UE shall generate a new SDP offer that contains:
— an "inactive" SDP attribute if the stream was previously set to "recvonly" media stream; or
— a "sendonly" SDP attribute if the stream was previously set to "sendrecv" media stream; or
for each media stream that shall be resumed, the invoking UE shall generate a new SDP offer that contains a “recvonly”, “sendonly”, or “sendrecv” SDP attribute based on the media stream characteristics.
If all the media streams in the SDP are affected:
for the media streams that shall be held, the invoking UE shall generate a session level direction attribute in the SDP that is set to:
— "inactive" if the streams were previously set to "recvonly" media streams; or
— "sendonly" if the streams were previously set to "sendrecv" media streams; or
for the media streams that shall be resumed, the invoking UE shall generate a session level direction attribute in the SDP that is set to “recvonly” or “sendrecv” based on the media stream characteristics.
Then the UE shall send the generated SDP offer in a re-INVITE (or UPDATE) request to the held UE.
6.3.2 AS
As a network option, the AS of the invoking UE may initiate the procedures for providing an announcement to the held user. The AS follows the 3rd party call control procedures as specified in [MMD Part-4] to provide announcement to the held user.
If the AS decides to play announcement, the AS shall include the MRFP’s SDP information in the re-INVITE or the UPDATE request before forwarding the request to the UE that is being put on hold.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
6 Call Hold 14 6.3 Service Procedures for Call Hold
If the AS decides to play announcement and when the AS receives responses containing the SDP answer to the hold request, then before forwarding the response to the invoking UE, the AS may set the SDP direction attribute for the media to be held to “inactive” if the received SDP answer contains a different value.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
7.1 Service Description 15 7 Call Waiting
7 Call Waiting
7.1 Service Description Call waiting service allows a user to be informed of an incoming call while the user is having an active call with another user.
7.2 Call Flows The scenario depicted in the following call flow assumes that the alerted user chooses to answer the new incoming (waiting) call. This is achieved by first putting the existing call on hold.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
7 Call Waiting 16 7.2 Call Flows
Figure 4 Call Waiting
UE-1 is on an active session with UE-2.
1~5. UE-3 sends INVITE to UE-1, attempting to establish a call. The INVITE matches initial filter trigger on UE-1’s S-CSCF and is routed through the AS for potential services during the call.
6~10. UE-1 returns a 180 Ringing provisional response. UE-1 can also return an 182 Queued provisional response to indicate that the call is on waiting.
11~21. PRACK/200OK is exchanged between UE-3 and UE-1 to ensure that the provisional response in the previous steps is received reliably. The subscriber at UE-1 is also notified of call from UE-3.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
7.3 Service Procedures for Call Waiting 17 7 Call Waiting
22. The subscriber at UE-1 decides to take the call from UE-3 and thus initiates call hold procedures from UE-1 to put UE-2 on hold.
23~27. UE-1 sends 200 OK to acknowledge the INVITE and accepts the call from UE-3.
28~32. UE-3 acknowledges with ACK message. UE-1 and UE-3 are now on active call with RTP media exchanged between them.
7.3 Service Procedures for Call Waiting
7.3.1 UE
The procedures specified in [MMD Part-4] shall apply with the following additions.
Upon receipt of a 182 (Queued) response, the originating UE may provide an indication to the user that the call is given call waiting treatment.
Upon receipt of an INVITE message, if the terminating UE has not reached the maximum number of waiting calls, the terminating UE shall provide an indication to the user that an incoming call is on waiting. The UE shall also send provisional responses to the INVITE following the procedures specified in [MMD Part-4]. When sending provisional responses, the terminating UE may send a 182 (Queued) response to indicate that the call is given call waiting treatment.
7.3.2 AS
There are no AS specific procedures other than those specified in [MMD Part-4].
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 18 8.1 Service Description
8 Call Transfer
8.1 Service Description Call transfer service allows a user involved in an IP multimedia communication to transfer the communication to a third user.
8.2 Call Flows This section provides the signaling flows for the following scenarios:
Blind Call Transfer without 3PCC
Consultative Call Transfer without 3PCC
Blind Call Transfer with 3PCC
Consultative Call Transfer with 3PCC
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.2 Call Flows 19 8 Call Transfe
8.2.1 Blind Call Transfer without 3PCC
Figure 5 Blind Call Transfer
UE-1 and UE-2 are on an active call. UE-1 decides to blind transfer UE-2 to UE-3.
1. UE-1 and UE-2 are in a normal call.
2. UE-1 first puts UE-2 on hold before initiating the blind call transfer.
3~5. UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by UE-1’s S-CSCF since the AS is included in the signaling path between UE-1 and UE-2 due to initial filter triggers in the original call setup process.
6. The AS replaces UE-3’s address in Refer-To header with a locally generated URI to make sure future message exchanges involved in the transfer process will go through the AS. The AS stores the mapping information between this local URI and UE-3’s address.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 20 8.2 Call Flows
7. The AS forwards the REFER to UE-2.
8~11. UE-2 acknowledges the REFER request with 202 Accepted response.
12~19. UE-1 sends BYE to UE-2 to terminate the call between them.
20~27. UE-2 can optionally notify UE-1 of the REFER processing status by sending NOTIFY.
28. UE-2 sends INVITE to the URI contained in Refer-To header to establish a call with the refer target. The INVITE is routed to UE-1’s AS since the URI is associated with this AS.
29. The AS translates the URI to UE-3’s address based on locally stored information.
30. The AS forwards the INVITE to UE-3.
31~40. UE-3 and UE-2 exchanges subsequent messages to establish a call. All the messages go through UE-1’s AS.
41~48. UE-2 sends NOTIFY to UE-1 to notify the status of the REFER processing.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.2 Call Flows 21 8 Call Transfe
8.2.2 Consultative Call Transfer without 3PCC
Figure 6 Consultative Call Transfer
UE-1 and UE-2 are on an active call. UE-1 decides to transfer UE-2 to UE-3, but before the actual transfer happens, UE-1 consults with UE-3 first for permission to transfer the call.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 22 8.2 Call Flows
1. UE-1 and UE-2 are in a normal call.
2. UE-1 first puts UE-2 on hold before initiating the call transfer.
3~11. UE-1 establishes call with UE-3 following normal procedures and gets UE-3’s permission to transfer UE-2.
12. UE-1 optionally puts UE-3 on hold before the call transfer.
13~15. UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by UE-1’s S-CSCF since the AS is included in the signaling path between UE-1 and UE-2 due to initial filter triggers in the original call setup process.
16. The AS replaces UE-3’s address in Refer-To header with a locally generated URI to make sure future message exchanges involved in the transfer process will go through the AS. The AS stores the mapping information between this local URI and UE-3’s address.
17. The AS forwards the REFER to UE-2.
18~21. UE-2 acknowledges the REFER request with 202 Accepted response.
22~29. UE-2 notifies UE-1 of the REFER processing status by sending NOTIFY.
30. UE-2 sends INVITE to the URI contained in Refer-To header to establish a call with the refer target. The INVITE is routed to UE-1’s AS since the URI is associated with this AS.
31. The AS translates the URI to UE-3’s address based on locally stored information.
32. The AS forwards the INVITE to UE-3.
33~42. UE-3 and UE-2 exchanges subsequent messages to establish a call. All the messages go through UE-1’s AS.
43~50. UE-2 sends NOTIFY to UE-1 to notify the status of the REFER processing.
51~58. UE-1 sends BYE to UE-2 to terminate the call between them after the transfer is completed.
59~66. UE-3 sends BYE to UE-1 to terminate the call between them after the replace operation is successful and the transfer is completed.
8.2.3 Blind Call Transfer with 3PCC
UE-1 and UE-2 are in an active call. UE-1 decides to blind transfer UE-2 to UE-3. In this scenario, UE-3’s initial offer (O1) is presented to the AS (acting on behalf of UE-1) in an 18x method. Since UE-2 is already on hold, the INVITE to stimulate the UE-3 offer is sent first. This expedites the off-hold processing of UE-2.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.2 Call Flows 23 8 Call Transfe
Figure 7 Blind Call Transfer with 3PCC (18x Offer)
UE-1 and UE-2 are on an active call. UE-1 decides to blind transfer UE-2 to UE-3.
1. UE-1 and UE-2 are in a normal call.
2. UE-1 first puts UE-2 on hold before initiating the blind call transfer.
3~5. UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by UE-1’s S-CSCF since the AS is included in the signaling path between UE-1 and UE-2 due to initial filter triggers in the original call setup process.
6~8. The AS acknowledges the REFER request with 202 Accepted response.
9-14. The AS can optionally notify UE-1 of the REFER processing status by sending NOTIFY.
15~17. UE-1 sends BYE to UE-2 to terminate the call between them.
18~20. The AS acknowledges the BYE with 200 OK (BYE) toward UE-1.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 24 8.2 Call Flows
21. The AS sends an INVITE to the URI contained in the Refer-To header to establish a call with UE-3. The AS picks the non-hold UE for first contact. The INVITE contains no SDP so that the UE-3 may present the initial offer, O1. As a configuration option, the AS may, in conjunction with an MRFP, begin playing audible ringback to UE-2.
22. UE-3 extends the initial offer (O1) in a 18x message. The offer includes an “a=sendrecv” attribute.
23. AS-1 sends a re-INVITE with offer, O1 received from UE-3, to UE-2.
24. UE-2 is on-hold when it receives the SDP offer with an “a=sendrecv” attribute from UE-3. This directs UE-2 to go off-hold and UE-2 responds with an answer (A1) with an “a=sendrecv” attribute in a 200 OK for the re-INVITE.
25. AS-1 acknowledges the INVITE with an ACK (INVITE).
26. The PRACK message for the 18x (message 22) contains the answer (A1) from UE-2.
27. UE-3 acknowledges with a 200 OK for the PRACK
28. UE-3 acknowledges the INVITE with a 200 OK for the INVITE
29. AS-1 closes the INVITE with ACK to UE-3. Upon receipt of the INVITE, if AS-1 had begun playing audible ringback in step 21, AS-1 removes audible ringback to UE-2.
Media between UE-2 and UE-3
30~32. The AS notifies UE-1 of the transfer complete with a NOTIFY (200 OK).
33~35. UE-1 acknowledges the NOTIFY with 200 OK (NOTIFY).
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.2 Call Flows 25 8 Call Transfe
8.2.4 Consultative Call Transfer with 3PCC
Figure 8 Consultative Transfer with 3PCC
UE-1 and UE-2 are on an active call. UE-1 decides to transfer UE-2 to UE-3, but before the actual transfer happens, UE-1 consults with UE-3 first for permission to transfer the call.
1. UE-1 and UE-2 are in a normal call.
2. UE-1 first puts UE-2 on hold before initiating the call transfer.
3~11. UE-1 establishes call with UE-3 following normal procedures and gets the permission from the user of UE-3 to transfer UE-2.
12. UE-1 optionally puts UE-3 on hold before the call transfer.
13~15. UE-1 sends REFER to UE-2 with the Refer-To header set to UE-3. The REFER is forwarded to the AS by UE-1’s S-CSCF since the AS is included in the signaling path between UE-1 and UE-2 due to initial filter triggers in the original call setup process.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 26 8.3 Service Procedures for Call Transfe
16~18. The AS acknowledges the REFER request with 202 Accepted response.
19~24. The AS can optionally notify UE-1 of the REFER processing status by sending NOTIFY.
25. The AS sends re-INVITE to UE-3 with no SDP information.
26. UE-3 returns 200 OK to the AS with an SDP offer (O1). The SDP offer proposes the call to be taken off hold.
27. The AS sends re-INVITE to UE-2 with the same SDP offer (O1).
28. UE-2 sends 200 OK with SDP answer (A1) to the AS.
29. The AS sends ACK to UE-2 with the SDP answer (A1). Now the end-to-end offer/answer exchange between UE-2 and UE-3 is completed.
30. The AS sends ACK to UE-3 to acknowledge the 200 OK response.
31~36. The AS sends NOTIFY to UE-1 to notify the status of the REFER processing.
37~42. UE-1 sends BYE and terminates the call leg between UE-1 and UE-2.
8.3 Service Procedures for Call Transfer
8.3.1 UE
The procedures specified in [MMD Part-4] shall apply with the following additions.
8.3.1.1 Actions at the transferor UE
A UE that initiates a transfer operation shall:
apply the procedure for holding the active call with the transferee as described in Section 6 of this specification;
apply the procedure for holding the active call with the transfer target as described in Section 6 of this specification, if the transferor UE has an active consultation call with the transfer target.
issue a REFER request in the original communications dialog, where:
— The request URI shall contain the SIP URI of the transferee as received in the Contact header field.
— The Refer-To header field shall indicate the public address of the transfer Target. If the transferor has an active consultation call with the transfer Target and the transfer target has indicated support for Replaces header [RFC3891], the URI shall also include a Replaces header containing the SIP dialog identifier between the transferor and the transfer Target.
r
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.3 Service Procedures for Call Transfer 27 8 Call Transfe
— The Referred-By header field may indicate the identity of the transferor.
After the REFER request is accepted by the other end with a 202 (Accepted) response, the transferor UE should get notifications of how the transferee's communication setup towards the transfer Target is progressing.
When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have successfully setup a communication, the transferor UE may terminate the original communication with the transferee UE, by sending a BYE message on the original dialog.
8.3.1.2 Actions at the transferee UE (without 3PCC)
When a REFER request is received in the context of a call transfer scenario (see clause 8.3.2.1.1), the transferee UE shall perform the following steps:
1. apply the procedure for holding the active communication with the transferor as described in Section 6 of this specification; and
2. apply normal REFER handling procedures according to [MMD Part-4].
8.3.1.3 Actions at the transfer target UE
The transfer target UE may indicate support for Replaces header during consultative call with the transferor UE.
The transfer target UE if not on a consultative call with the transferor UE, upon receiving an initial INVITE request with no SDP content, shall send reliable provisional responses according to [MMD Part-4] with an SDP offer. The content of the SDP offer could be derived based on the service information, if available in the INVITE.
The transfer target UE if on a consultative call with the transferor UE, upon receiving a re-INVITE request within the existing dialog with no SDP content, shall send 200OK response according to [MMD Part-4] with an SDP offer. The content of the SDP offer is derived based on the media characteristics of the existing consultative call.
8.3.2 AS
The procedures specified in [MMD Part-4] shall apply with the additions in this section.
8.3.2.1 Actions at the transferor AS
8.3.2.1.1 Invocation of CT service
8.3.2.1.1.1 Prerequisite for invocation of the CT service
For CT to be provided to end users acting as transferor, the end user's AS providing CT shall be in the signalling path for all communications.
8.3.2.1.1.2 Determine whether the CT applies
The transferor AS is the one executing the CT service logic, which is invoked by the transferor sending a REFER request.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 28 8.3 Service Procedures for Call Transfe
8.3.2.1.1.2.1 REFER request received on a separate dialog
CT does not apply in this case.
NOTE: That transfer could be initiated by REFER request on a separate dialog when the network supports GRUU. Since this is currently not specified in [MMD Part-4], REFER on separate dialogs can not be used for transfer of communication.
8.3.2.1.1.2.2 REFER request received in the to-be-transferred dialog
To know whether CT service applies on a REFER request sent by the served user, the following criteria shall apply before the CT logic is executed:
The REFER request's request-URI (transferee) is targeted at the same UE instance that is involved in the context of the to-be-transferred dialog.
The REFER request's Refer-To header contains a URI so that the method constructed from the URI is compliant to [RFC3261].
Any REFER request that does not comply with these criteria shall not invoke the CT service and is, depending on operator policy:
— Rejected.
— Handled by another service.
— Proxied on.
8.3.2.1.2 Procedures for CT without 3PCC
When a REFER request is received that invokes the CT service (see Section 8.3.2.1.1), the AS shall perform the following actions:
1. Create a new CT Session Identifier URI. The URI shall be created in such a way that a new dialog using this URI shall be routed back to this AS and can be easily correlated with the current REFER dialog.
2. The AS stores the value of the Refer-To header field (transfer Target) from the REFER request and links it to the CT Session Identifier URI.
3. The AS replaces the Refer-To header field in the request with the CT Session Identifier URI (this ensures that the transferor AS remains in the signalling path when the transferee sets up the communication with the transfer Target).
4. If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains a valid identity of the transferor (served user). If not the AS will replace the Referred-By header with a valid value matching the transferor’s P-Asserted-Identity.
5. If no Referred-By header is available in the request, a Referred-By header is added that matches the transferor’s P-Asserted-Identity.
6. The AS sends the REFER request on to the transferee as defined in [MMD Part-4].
When an INVITE is received with a CT Session Identifier URI created earlier when the served user requested transfer of an ongoing communication, the AS shall perform the following actions:
r
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8.3 Service Procedures for Call Transfer 29 8 Call Transfe
1. Replace the request URI in the INVITE with the stored transfer Target URI linked to the CT Session Identifier URI.
2. If a Referred-By header is available in the request, the AS verifies if the provided Referred-By header contains a valid identity of the served user. If the identity is not valid the AS shall replace the Referred-By header with a valid value matching the transferor’s P-Asserted-Identity.
3. If no Referred-By header is available in the request a Referred-By header is added that matches the transferor’s P-Asserted-Identity.
NOTE: If needed, the AS may generate charging events to charge for the extra leg.
4. The INVITE request is forwarded towards the transfer Target using basic communication procedures [MMD Part-4].
8.3.2.1.3 Procedures for CT with 3PCC
When a REFER request is received that invokes the CT service (see Section 8.3.2.1.1), the AS shall follow procedures specified in [MMD Part-4] for 3PCC as an initiating B2BUA:
terminate the REFER request from the transferor UE by sending 202 Accepted response and subsequent NOTIFY requests;
generate an INVITE request without SDP content body based on the Refer-To header in the REFER request. The AS shall not include Replaces header in this INVITE request;
send the INVITE request to the transfer target as either an initial INVITE if there is no consultative call between the transferor UE and the transfer target or a re-INVITE over the existing dialog if there is a consultative call between the transferor UE and the transfer target.
NOTE: For Consultative Transfer, the transfer target is not aware of the calling identity change from the transferor to the transferee since the re-INVITE is sent over the existing dialog.
Upon receiving a reliable response (reliable 18x response or 200 OK response) to the INVITE request from the transfer target UE with SDP offer information in the message body, the AS shall generate a re-INVITE request to the transferee UE. The re-INVITE shall include the media information in the SDP offer that matches what was received from the transfer target UE. The re-INVITE request is sent to the transferee UE over the existing dialog.
Upon receiving a reliable response (e.g., 200 OK) to the re-INVITE request from the transferee UE containing an SDP answer in the message body, the AS shall include the SDP answer into the next eligible request toward the transfer target as an answer to the original SDP offer. The next eligible request may be one of the following:
PRACK request for a reliable 18x provisional response; or,
ACK request for 200 OK response.
Upon successful completion of the 3PCC procedure between the transferee and the transfer target, the AS shall send a NOTIFY request to the transferor to indicate that the call transfer has been completed based on the REFER request.
r
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
8 Call Transfer 30 8.3 Service Procedures for Call Transfe
r
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.1 Service Description 31 9 Call Forwarding
9 Call Forwarding
9.1 Service Description Call forwarding service allows a called user to forward a communication request to another destination. The originating user may or may not be notified that the call is being forwarded.
9.2 Call Flows This section provides the signaling flows for the following scenarios:
Call Forwarding Unconditional (CFU)
Call Forwarding on Busy (CFB)
Call Forwarding on No-Answer (CFNA)
In all the call flows in this section, it is assumed that UE-2 uses the same P-CSCF/S-CSCF as UE-1, but this is not required.
181 (Call is being forwarded) message is optional.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 32 9.2 Call Flows
9.2.1 Call forwarding unconditional
Figure 9 Call Forwarding Unconditional
1~2. UE-3 sends INVITE to UE-1, attempting to establish a call. The INVITE is forwarded to UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
3. The AS executes CFU service on behalf of UE-1.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.2 Call Flows 33 9 Call Forwarding
4~5. The AS optionally sends “181 Call is Being Forwarded” to notify UE-3 that the call is being forwarded.
6~8. The AS forwards the INVITE to UE-2 based on the call forwarding setting.
9~33. UE-2 and UE-3 exchange subsequent messages to establish a call.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 34 9.2 Call Flows
9.2.2 Call forwarding on busy
Figure 10 Call forwarding on busy
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.2 Call Flows 35 9 Call Forwarding
1~5. UE-3 sends INVITE to UE-1, attempting to establish a call. The INVITE is routed through UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
6~8. UE-1 answers the INVITE with “486 Busy Here” to indicate that it is busy. The response is intercepted by the AS.
9~11. The AS sends ACK to acknowledge the 486 response from UE-1.
12. The AS executes CFB service on behalf of UE-1.
13~14. The AS optionally sends “181 Call is Being Forwarded” to notify UE-3 that the call is being forwarded.
15~17. The AS forwards the INVITE to UE-2 based on the call forwarding setting.
18~42. UE-2 and UE-3 exchange subsequent messages to establish a call.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 36 9.2 Call Flows
9.2.3 Call forwarding on no-answer
Figure 11 Call forwarding on no-answer
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.3 Service Procedures for Call Forwarding 37 9 Call Forwarding
1~2. UE-3 sends INVITE to UE-1, attempting to establish a call. The INVITE is forwarded to UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
3~5. The AS forwards the INVITE to UE-1.
6~8. UE-1 is alerted following the normal call setup procedure with “180 Ringing” sent back to UE-3 reliably. The “180 Ringing” response arrives at the AS.
9. The AS executes CFNA service on behalf of UE-1 and starts a timer.
10~21. The AS forwards the “180 Ringing” to UE-3 reliably. The response is acknowledged by UE-3.
22. The timer at the AS expires before the AS receives any final response from UE-1.
23~28. The AS sends CANCEL to UE-1 to cancel the INVITE request.
29~34. UE-1 sends “487 Request Terminated” final response and the AS sends ACK to acknowledge.
35~36. The AS optionally sends “181 Call is Being Forwarded” to notify UE-3 that the call is being forwarded.
37~39. In parallel to step 23~36, the AS forwards the INVITE to UE-2 based on the call forwarding setting.
40~64. UE-2 and UE-3 exchange subsequent messages to establish a call.
9.3 Service Procedures for Call Forwarding
9.3.1 UE
The procedures specified in [MMD Part-4] shall apply with the additions in this section.
9.3.1.1 Actions at the originating UE
When CF has occurred on the served user side, the originating UE may receive a 181 (Call is being forwarded) response according to the procedures described in [MMD Part-4].
The information given by the History-Info header could be displayed to the user.
9.3.2 AS
The procedures specified in [MMD Part-4] shall apply with the additions in this section.
For CFD service, the AS procedure is the same as either CFB or CFNA depending on the forwarding condition: If the AS receives busy indication from the user, then the AS shall follow the same procedures as in CFB; if the no-answer timer expires, then the AS shall follow the same procedures as in CFNA.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 38 9.3 Service Procedures for Call Forwarding
9.3.2.1 Actions at the AS of the forwarding User
9.3.2.1.1 Checking of the forwarding limits
When receiving an INVITE request and the AS determines that it must forward a communication:
the AS shall check if forwarding the communication exceeds the number of forwardings allowed within the network. The number of forwardings shall be calculated by the entries including a Cause parameter given by the History-Info header field, if the History-Info header field is present. If the number of forwardings exceeds the given limit, then the communication shall be released; and
if the communication has already undergone one or more forwarding(s), the entries in the Index entries parameter shall be examined to see if another forwarding is allowed due to network provider allowed limit of forwardings.
If the number of forwardings exceeds the given limit then the following response sent to the originating user shall apply:
a. CFB, 486 (Busy here) shall be sent;
b. CFNA, 408 (Request Timeout) shall be sent;
c. CFU, 480 (Temporarily unavailable) shall be sent;
In all cases, a Warning header field indicating that the communication is released due to the extension of forwarding hops (e.g. "Too many forwardings appeared") shall be sent.
9.3.2.1.2 Setting of the forwarding parameters by the AS
9.3.2.1.2.1 Overview
After checking the limit of forwardings, the following settings of the INVITE request shall be performed.
9.3.2.1.2.2 First forwarding; no History-Info header received
When this is the first forwarding the communication has undergone, the following information is to be set in the retargeted request:
the forwarding party address;
the forwarded-to party address;
forwarding information.
The following header fields shall be included or modified with the specified values:
a. The Request URI - shall be set to the SIP URI or Tel URI where the communication is to be forwarded.
b. The History-Info Header field - Two hist-info entries that shall be generated.
1. The first entry includes the hi-targeted-to-uri of the served user.
The privacy header "history" shall be escaped within the hi-targeted-to-uri, if:
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.3 Service Procedures for Call Forwarding 39 9 Call Forwarding
— the served user wishes privacy (e.g. the served user is subscribed to the CIR Service);
The Index is set to index = 1 according to the rules specified in [RFC4244].
2. The second entry includes the hi-targeted-to-uri of the address where the communication is forwarded to. The index is set to index = 1.1, The cause-param parameter (redirecting reason and redirecting indicator) included in the history-info header field shall be set according to the forwarding conditions and notification subscription option.
The mapping between the forwarding conditions and the coding of the Reason parameter is as follows:
— CFB, the cause value "486 " as defined by [RFC4458] shall be used.
— CFNA, the cause value "408" as defined by [RFC4458] shall be used.
— CFU, the cause value "302" as defined by [RFC4458] shall be used.
according to the rules specified in [RFC4244].
c. The To header field - If the served user does not want to reveal its identity to the forwarded-to party, then the To header shall be changed the URI where the communication is forwarded to. The served user does not want to reveal its identity when one of the following conditions holds true:
if the served user wishes privacy (e.g. the served user is subscribed to the CIR Service);
In all other cases, the To header shall not be changed.
9.3.2.1.2.3 Subsequent forwarding; a History-Info header received
When this is the second or greater forwarding the communication has undergone, a new history-info entry shall be added to the History-Info header field according to the rules defined in [RFC4244]. The following information has to be added to the retargeted request:
the forwarded-to party address;
forwarding information.
The following header fields shall be included or modified with the specified values:
a. Request URI - shall be set to the SIP URI or Tel URI where the communication is to be forwarded.
b. History-Info Header - The history entry representing the served user may be modified. One history entry is added.
1. For the history entry representing the served user, the privacy header with the value "history" shall be escaped within the hi-targeted-to-uri, if:
— the served user wishes privacy (e.g. the served user is subscribed to the CIR Service);
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 40 9.3 Service Procedures for Call Forwarding
If the history is already escaped with the correct privacy value, no modification is needed.
In all other cases, the history entry representing the served user shall not be changed.
2. A history entry shall be added where the hi-targeted-to-uri shall be set to the public user identity where the communication is forwarded to. Cause-param parameter (redirecting reason) included in the History-Info header field shall be set according to the forwarding conditions and notification subscription option.
The mapping between the forwarding conditions and the coding of the cause-param parameter is as follows:
CFB, the Cause value "486" as defined by [RFC4458] shall be used.
CFNA, the Cause value "408" as defined by [RFC4458] shall be used.
CFU, the Cause value "302" as defined by [RFC4458] shall be used.
The Index shall be incremented according to the Basic Forwarding rules specified in section 4.3.3.1.3 "Indexing in the History-Info Header" of [RFC4244] and the new level index "1" shall be used.
c. To header- If the served user does not want to reveal its identity to the forwarded-to party, then the To header shall be changed to the URI where the communication is forwarded to. The served user does not want to reveal its identity when one of the following conditions holds true:
if the served user wishes privacy (e.g. the served user is subscribed to the CIR Service);
In all other cases, the To header shall not be changed.
9.3.2.1.3 Forwarding procedures at the forwarding AS
The forwarding AS shall continue the communication depending on the service that is causing the forwarding:
1. CFU or CFB when network determines that the user is busy
The AS shall continue in the following manner:
If the notification procedure of the originating user is supported, then the originating user shall be notified as described in clause 9.3.2.1.4.
An INVITE request containing the forwarded-to URI shall be sent to the (outgoing) S-CSCF. The INVITE request shall include the parameter information as described in clause 9.3.2.1.2.
2. CFNA
After receiving the first 180 (Ringing) response, the no reply timer shall be started with value between 20 and 40 seconds. If forking is provided by the S-CSCF a further received 180 (Ringing) response does not refresh the timer.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9.3 Service Procedures for Call Forwarding 41 9 Call Forwarding
When the AS receives a 200 (OK) response, the no reply timer shall be terminated and the call follows the Basic call procedure as described within [MMD Part-4]. Other open early dialogs shall be terminated as described within [MMD Part-4].
When the no reply timer expires:
The dialog(s) to the forwarding user shall be terminated e.g. by sending a CANCEL request or BYE request according to the rules and procedures in [RFC3261].
If the notification procedure of the originating user is supported, then the originating user shall be notified as described in clause 9.3.2.1.4.
An INVITE request is sent to the (outgoing) S-CSCF towards the forwarded-to user. The INVITE request shall include the parameter information as described in Section 9.3.2.1.2.
3. CFB with user determined busy
The AS shall perform the following actions:
The received 486 Busy shall be acknowledged with a ACK.
If the notification procedures of the originating user is supported, then the originating user shall be notified as described in clause 9.3.2.1.4.
An INVITE message containing the forwarded-to URI is sent to the outgoing S-CSCF. The INVITE request shall include the parameter information as described in Section 9.3.2.1.2.
9.3.2.1.4 Notification procedures of the originating user
When Communication Forwarding occurs, a 181 (Call Is Being Forwarded) response may be sent towards the originating user.
The following header fields shall be included or modified with the specified values:
a. The P-Asserted-Identity includes the URI of the forwarding user.
b. The Privacy header with the value "id" shall be included, if the served user wishes privacy (e.g. the served user is subscribed to the TIR Service).
c. The following entries shall be added to the History-Info header field:
1. If this is the first forwarding then the first entry shall be populated with the hi-targeted-to-uri of the served user. The Index is set to index = 1 according to the rules specified in [RFC4244].
2. On the history entry that represents the served user, the privacy header with value "history" shall be escaped within the hi-targeted-to-uri, if:
— the served user wishes privacy (e.g. the served user is subscribed to the TIR Service); or
— if the history is already escaped with the correct privacy value no modification is needed;
— in all other cases the history entry representing the served user shall not be changed.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
9 Call Forwarding 42 9.3 Service Procedures for Call Forwarding
3. A history entry shall be added according to the rules of 9.3.2.1.2.3 item b.2. For this entry the privacy header with value "history" shall be escaped within the hi-targeted-to-uri.
Additionally the AS may initiate an announcement towards the calling user in order to inform the user about the forwarding.
9.3.2.2 Actions at the AS of the forwarded to User
The AS shall store the History-Info Header of an incoming Request if the History-Info header is included in the request.
If a 180, 181 or 200 response does not contain a History-Info header field, the AS shall include the stored History-Info header field and if forwarded to user is subscribed to the TIR service the Privacy header field of all responses and the priv-value of the last entry in the History-Info header field shall be set to "history".
NOTE: A response including no History-Info header Field is coming from an untrusted entity or the History-Info header field is not included due to the privacy status within the SIP request.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10.1 Service Description 43 10 Caller ID Presentation/Restriction
10 Caller ID Presentation/Restriction
10.1 Service Description Caller Identity Presentation (CIP) service provides the terminating user with the trusted identity information to identify the originating user
Caller Identity Restriction (CIR) service enables the originating user to prevent presentation of its identity information to the terminating user.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10 Caller ID Presentation/Restriction 44 10.2 Call Flows
10.2 Call Flows
10.2.1 Caller ID Presentation
Figure 12 Caller ID Presentation
1~2. UE-2 sends INVITE to UE-1, attempting to establish a call. A P-Asserted-Identity header containing UE-2’s public identity is inserted to the INVITE by the P-CSCF serving UE-2. The INVITE is forwarded to UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
3. The AS checks that UE-1 has CIP service and does not remove the P-Asserted-Identity header and any related Privacy header.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10.2 Call Flows 45 10 Caller ID Presentation/Restriction
4~6. The AS forwards the INVITE to UE-1.
7~31. UE-1 and UE-2 exchange subsequent messages to establish a call.
10.2.2 Caller ID Restriction
Figure 13 Caller ID Restriction
1~3. UE-1 sends INVITE to UE-2, attempting to establish a call. The INVITE is forwarded to UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF. UE-1 sets Privacy header in the INVITE to “id”. The P-CSCF adds P-Asserted-Identity header with UE-1’s identity into the
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
54
55
56
57
58
59
60
10 Caller ID Presentation/Restriction 46 10.3 Service Procedures for CIP/CIR
53
INVITE, the value of P-Asserted-Identity is based on the P-Preferred-Identity received from UE-1.
4. The AS checks that UE-1 has CIR service and can modify the From header to hide the identity information.
Note: The AS does not remove the P-Asserted-Identity header or the Privacy header. Instead, this step just makes sure that Privacy header is set properly set so that the terminating network can remove the identity information.
5~6. The AS forwards the INVITE to UE-2.
7~31. UE-2 and UE-1 exchange subsequent messages to establish a call.
10.3 Service Procedures for CIP/CIR
10.3.1 UE
The UE shall support the procedures specified in [MMD Part-4] with the following additions.
10.3.1.1 Actions at the originating UE
As part of basic communication, the originating UE may insert a P-Preferred-Identity header field in any initial SIP request for a dialog or in any SIP request for a standalone transaction as a hint for creation of a public user identity as described in [MMD Part-4].
NOTE 1: According to [MMD Part-4], the UE may include any of the following in the P-Preferred-Identity header field:
a public user identity which has been registered by the user;
a public user identity returned in a registration state event package of a NOTIFY request as a result of an implicit registration that was not subsequently deregistered or has expired; or
any other public user identity which the user has assumed by mechanisms outside the scope of [MMD Part-4] to have a current registration.
If the originating user wishes to override the default setting of "presentation not restricted" of the CIR service in temporary mode:
The originating UE shall include an "anonymous" From header field. The convention for configuring an anonymous From header field described in [RFC3323] and [RFC3325] should be followed; e.g..:
— From: "Anonymous" <sip:[email protected]>;tag= 192830o1774.
If only the P-Asserted-Identity needs to be restricted the originating UE shall include a Privacy header field set to "id" in accordance with [RFC3323] and [RFC3325].
If all headers containing private information need to be restricted the originating UE shall include a Privacy header field set to "header" in accordance with [RFC3323].
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10.3 Service Procedures for CIP/CIR 47 10 Caller ID Presentation/Restriction
If the originating user wishes to override the default setting of "presentation restricted" of the CIR service in temporary mode:
The originating UE shall include a Privacy header field of privacy type "none" in accordance with [RFC3323].
10.3.1.2 Actions at the terminating UE
A terminating UE shall support the receipt of one or more P-Asserted-Identity header fields in SIP requests initiating a dialog or standalone transactions, each one containing a public user identity of the originating user. The UE may present the information to the user.
NOTE 1: If no P-Asserted-Identity header fields are present, but a Privacy header field was present, then the one or more identities may have been withheld due to presentation restriction.
NOTE 2: If neither P-Asserted-Identity header fields nor a Privacy header field are present, then the network provided identities may not have been available (due to, for example, interworking with other networks), or the user may not hold a subscription to the CIP service.
NOTE 3: A user provided identity may also be available, within the From header field of the request. The MMD network can not take any responsibility for the content of the From header field.
10.3.2 AS
10.3.2.1 Actions at the AS serving the originating UE
For an originating user that subscribes to the CIR service in "permanent mode, the AS shall insert a Privacy header field set to "id" or "header" based on the subscription option if the request does not include a Privacy header field that is set to the corresponding value. If the request includes a Privacy header field that is set to "none", the AS shall remove the "none" value from the Privacy header field. Additionally, as an originating option, the AS may either modify the From header field to remove the identification information, or add a Privacy header field set to "user".
For an originating user that subscribes to the CIR service in "temporary mode" with default "restricted", if the request does not include a Privacy header field, or the request includes a Privacy header field that is not set to "none", the AS shall insert a Privacy header field set to "id" or "header" based on the subscription option. Additionally, as an originating option, the AS may either modify the From header field to remove the identification information, or add a Privacy header field set to "user".
NOTE: If the request includes a Privacy header field that is set to "none", the text above requires the AS to remove the "none" value from the Privacy header field. This requirement is known to be in conflict with RFC3323.
NOTE: When the CIR service is used, the originating UE is supposed to already have removed identity information. However because this UE is not trusted, this is also done by the AS to ensure that this information is removed.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
10 Caller ID Presentation/Restriction 48 10.3 Service Procedures for CIP/CIR
For an originating user that subscribes to the CIR service in "temporary mode" with default "not restricted", if the request includes a Privacy header field is set to "id" or "header", as an originating network option, the AS, may modify the From header field to remove the identification information. As an originating network option, if the "no screening" special arrangement does not exist with the originating user, the network may attempt to match the information in the From header with the set of registered public identities of the originating user. If a match is not found, the AS may set the From header to the SIP URI that includes the default public user identity.
10.3.2.2 Actions at the AS serving the terminating UE
If a terminating user does not subscribe to CIP service, an AS shall remove any P Asserted Identity and Privacy header fields included in the request. Additionally, the Application Server may as a network option anonymize the contents of the From header by setting it to a default non significant value. As a network option, if the terminating user has an override category, the AS shall send the P Asserted Identity headers and remove the Privacy header fields.
When the Privacy header field is set to "id", with the exception of the cases listed above, the AS should not remove this Privacy header entry.
NOTE: The priv-value "id" in the Privacy header will be used by the terminating UE to distinguish the request of CIR by the originating user.
If the request includes the Privacy header field set to "header" the AS shall not anonymize the contents of all headers containing private information in accordance with [RFC3323] and [RFC3325].
NOTE: The Privacy header is enforced according to [RFC3323] and [RFC3325] either by the S-CSCF or a network entity at the edge of the trust domain.
If the request includes the Privacy header field set to "user" the AS shall remove or anonymize the contents of all "user configurable" headers in accordance with [RFC3323] and [RFC3325]. In the latter case, the AS may need to act as transparent back to back user agent as described in [RFC3323].
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
11.1 Service Description 49 11 Terminating ID Presentation/Restriction
11 Terminating ID Presentation/Restriction
11.1 Service Description Terminating Identity Presentation (TIP) service provides the originating user with the trusted identity information to identify the terminating user.
Terminating Identity Restriction (TIR) service allows the terminating user to prevent presentation of the terminating identity information to originating user.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
11 Terminating ID Presentation/Restriction 50 11.2 Call Flows
11.2 Call Flows
11.2.1 Terminating ID Presentation
UE-1 P-CSCF S-CSCF AS
27. ACK28. ACK
31. ACK
RTP Media
1. INVITE 2. INVITE 3. INVITE
4. INVITE
5. INVITE
6. 180 Ringing
7. 180 Ringing
8. If no TIP service, remove P-Asserted-Identity and Privacy
Headers; otherwise, no change.
29. ACK
30. ACK
UE-2
9. 180 Ringing10. 180 Ringing
11. 180 Ringing
12. PRACK13. PRACK
14. PRACK
15. PRACK
16. PRACK
17. 200 OK (PRACK)
18. 200 OK (PRACK)
19. 200 OK (PRACK)20. 200 OK (PRACK)
21. 200 OK (PRACK)22. 200 OK (INVITE)
23. 200 OK (INVITE)
24. 200 OK (INVITE)25. 200 OK (INVITE)
26. 200 OK (INVITE)
Figure 14 Terminating ID Presentation (No Subscription)
1~5. UE-1 sends INVITE to UE-2, attempting to establish a call. The INVITE is routed through UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
6~7. UE-2 answers with “180 Ringing” response, which is routed to the AS.
8. The AS checks whether UE-1 has TIP service or not. If no, the AS removes any P-Asserted-Identity headers or Privacy headers included in the response; if yes, the AS does not need to remove those headers.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
11.2 Call Flows 51 11 Terminating ID Presentation/Restriction
9~11. The AS forwards the provisional response to UE-1.
12~31. UE-1 and UE-2 exchange subsequent messages to establish a call.
11.2.2 Terminating ID Restriction
UE-1 P-CSCF S-CSCF AS
31. ACK30. ACK
27. ACK
RTP Media
5. INVITE4. INVITE
2. INVITE
3. INVITE
1. INVITE
28. ACK
29. ACK
UE-2
6. 180 Ringing
9. If TIR service activated, include Privacy header with
“id”.
7. 180 Ringing8. 180 Ringing
10. 180 Ringing
16. PRACK15. PRACK
13. PRACK
14. PRACK
12. PRACK
21. 200 OK (PRACK)
19. 200 OK (PRACK)
20. 200 OK (PRACK)
18. 200 OK (PRACK)17. 200 OK (PRACK)
11. 180 Ringing
26. 200 OK (INVITE)
24. 200 OK (INVITE)
25. 200 OK (INVITE)
23. 200 OK (INVITE)22. 200 OK (INVITE)
Figure 15 Terminating ID Restriction
1~5. UE-2 sends INVITE to UE-1, attempting to establish a call. The INVITE is forwarded to UE-1’s AS due to initial filter triggers on UE-1’s S-CSCF.
6~8. UE-1 answers with “180 Ringing” response, which is routed to the AS.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
11 Terminating ID Presentation/Restriction 52 11.3 Service Procedures for TIP/TIR
8. The AS checks that UE-1 has TIR service. If no Privacy header is included, the AS includes a Privacy header with value “id”.
10~11. The AS forwards the provisional response to UE-2.
12~31. UE-2 and UE-1 exchange subsequent messages to establish a call.
11.3 Service Procedures for TIP/TIR
11.3.1 UE
The UE shall follow the procedures specified in [MMD Part-4] with the additions in this section.
11.3.1.1 Actions at the originating UE
A UE that supports the TIP service signaling procedures shall support the receipt, in SIP responses to SIP requests initiating a dialog or for standalone transactions, one or more P-Asserted-Identity headers, each one containing a network-provided identity information of the terminating user.
If no P-Asserted Identity header fields are present, but a Privacy header field set to "id" was present, then the network-provided identity information was withheld due to presentation restriction.
If neither P-Asserted-Identity header fields nor a Privacy header fields set to "id" are present, then the network-provided identity information was not available (due, for example, to interworking with other networks).
Once a 2xx response is received, the P-Asserted Identity header field of the first 2xx response is used, e.g. when presenting the identity to the user.
NOTE: Any P-Asserted-Identity received in a provisional response is outside the scope of this service.
11.3.1.2 Actions at the terminating UE
The destination UE, if requesting that its identity be kept private from the originating user, may include a Privacy header with privacy type of "id" in any non-100 responses it sends upon receipt of a SIP request.
NOTE: It is assumed that TIR subscribers support [RFC3325].
11.3.2 AS
The AS shall follow the procedures specified in [MMD Part-4] with the additions in this section.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
11.3 Service Procedures for TIP/TIR 53 11 Terminating ID Presentation/Restriction
11.3.2.1 Actions at the AS serving the originating UE
NOTE 1: If the terminating user requests privacy the S-CSCF removes the P-Asserted-Identity header field as part of the basic communication procedures defined in [MMD Part-4].
If an originating user does not subscribe to the TIP service, any P-Asserted Identity header fields and Privacy header fields included in the SIP response shall be removed.
When the Privacy header field is set to "id", with the exception of the cases listed above, the AS should not remove this Privacy header entry.
NOTE 2: The priv-value "id" in the Privacy header will be used by the originating UE to distinguish the request of TIR by the terminating user.
If the response includes the Privacy header field set to "header" the AS shall not anonymize the contents of all headers containing private information in accordance with [RFC3323] and [RFC3325].
NOTE: The Privacy header is enforced according to [RFC3323] and [RFC3325] either by the S-CSCF or a network entity at the edge of the trust domain.
If the response includes the Privacy header field set to "user" the AS shall remove or anonymize the contents of all "user configurable" headers in accordance with [RFC3323] and [RFC3325]. In this case, the AS may need to act as transparent back to back user agent as described in [RFC3323].
11.3.2.2 Actions at the AS serving the terminating UE.
For a terminating user who subscribes to the TIR service in "permanent mode", if a SIP response to a SIP request does not include a Privacy header field, the AS shall insert a Privacy header field set to "user, header, id".
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12 Three-Way Conferencing 54 12.1 Service Description
12 Three-Way Conferencing
12.1 Service Description Three-Way Conferencing (3WC) service provides the subscriber the capability to add a third party to an established two-party call, so that all three parties may communicate at the same time.
12.2 Call Flows
12.2.1 3WC without 3PCC
NOTE: This flow does not illustrate the presence of an AS associated with UE-1 in the session setup signaling path.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12.2 Call Flows 55 12 Three-Way Conferencing
Media Path to UE-2
2. UE-1 Puts UE-2 on hold
5. INVITE (CS) 6. INVITE (CS) 7. INVITE (CS)
8. Interaction for creating Conference
10. 200 OK (INVITE)11. 200 OK (INVITE)
12. ACK 13. ACK
9. 200 OK (INVITE)
14. ACK
Media Path between UE-1 and CS15. REFER(UE-2) w Refer-
To: CS16. REFER(UE-2) w Refer-
To: CS 17. REFER(UE-2) w Refer-To:CS
19. 202 Accepted20. 202 Accepted 18. 202 Accepted
34. NOTIFY (200 OK)35. NOTIFY (200 OK)36. NOTIFY (200 OK)
37. 200 OK (NOTIFY) 38. 200 OK (NOTIFY) 39. 200 OK (NOTIFY)
29. Interaction for resource for an additional participant
27. INVITE
28. INVITE
30. 200 OK (INVITE)
31. 200 OK (INVITE)
33. ACK
32. ACK
42. BYE41. BYE40. BYE
Media to UE-2
44. 200 OK (BYE)45. 200 OK (BYE) 43. 200 OK (BYE)
46. REFER(UE-3) w Refer-To: CS
47. REFER(UE-3) w Refer-To: CS 48. REFER(UE-3) w Refer-To: CS
50. 202 Accepted51. 202 Accepted 49. 202 Accepted
65. NOTIFY (200 OK)66. NOTIFY (200 OK)67. NOTIFY (200 OK)
68. 200 OK (NOTIFY) 69. 200 OK (NOTIFY) 70. 200 OK (NOTIFY)
60. Interaction for resource for an additional participant
58 INVITE
59. INVITE
61. 200 OK (INVITE)
62. 200 OK (INVITE)
64. ACK
63. ACK
73. BYE72. BYE71. BYE
75. 200 OK (BYE)76. 200 OK (BYE) 74. 200 OK (BYE)
52. NOTIFY (100 Trying)53. NOTIFY (100 Trying)54. NOTIFY (100 Trying)
55. 200 OK (NOTIFY) 56. 200 OK (NOTIFY) 57. 200 OK (NOTIFY)
21. NOTIFY (100 Trying)22. NOTIFY (100 Trying)23. NOTIFY (100 Trying)
24. 200 OK (NOTIFY) 25. 200 OK (NOTIFY) 26. 200 OK (NOTIFY)
UE-1 P-CSCF S-CSCF AS/MRFC
MRFP
UE-2 UE-3
Media to UE-3
1. UE-1 and UE-2 is in a multimedia session
Media Path to UE-3
3. UE-1 call UE-3 and establishes a session
4. UE-1 puts UE-3 on hold
Figure 16 Three-way conferencing
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12 Three-Way Conferencing 56 12.2 Call Flows
UE-1 and UE-2 are in an active call. UE-1 decides to add UE-3 to make it a 3-way conferencing call.
1. UE-1 and UE-2 are in an active call.
2. UE-1 puts UE-2 on hold before invoking the 3WC with UE-3.
3. UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3’s permission to start the 3WC.
4. UE-1 puts UE-3 on hold before invoking the 3WC procedures.
5~7. UE-1 sends INVITE to the conference server to establish a conference session.
8. The CS coordinates with MRFP to allocate conference resources.
9~14. The CS sends 200 OK and receives ACK from UE-1.
15~20. UE-1 sends REFER to UE-2 with Refer-To set to the address of the CS; UE-2 accepts the REFER.
21~26. UE-2 optionally sends NOTIFY to UE-1 to indicate that UE-2 is acting on the REFER request.
27~28. UE-2 sends INVITE to the CS to join the conference.
29. The CS coordinates with MRFP to allocate more resources.
30~33. The CS sends 200 OK to UE-2 and receives ACK.
34~39. UE-2 sends NOTIFY to UE-1 to indicate that it has finished action required by the REFER request.
40~45. UE-1 sends BYE to terminates the call between itself and UE-2.
46~51. In parallel to step 22~52, UE-1 sends REFER to UE-3 with Refer-To set to the address of the CS; UE-3 accepts the REFER.
52~57. UE-3 sends NOTIFY to UE-1 to indicate that UE-3 is acting on the REFER request.
58~59. UE-3 sends INVITE to the CS to join the conference.
60. The CS coordinates with MRFP to allocate more resources.
61~64. The CS sends 200 OK to UE-3 and receives ACK.
65~70. UE-3 sends NOTIFY to UE-1 to indicate that it has finished action required by the REFER request.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12.2 Call Flows 57 12 Three-Way Conferencing
71~76. UE-1 sends BYE to terminates the call between itself and UE-3.
12.2.2 3WC with 3PCC
Figure 17 3WC with 3PCC
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12 Three-Way Conferencing 58 12.2 Call Flows
UE-1 and UE-2 are in an active call. UE-1 decides to add UE-3 to make it a 3-way conferencing call.
1. UE-1 and UE-2 are in an active call. The AS is put on the signaling path of this call by invoking the iFC. The dialog ID between the AS and UE-2 is D1.
2. UE-1 puts UE-2 on hold before invoking the 3WC with UE-3.
3. UE-1 establishes a call with UE-3 following normal call setup procedure and gets UE-3’s permission to start the 3WC. The AS is put on the signaling path of this call by invoking the iFC.
4. UE-1 decides to covert the two on-going calls into a 3-way call and puts UE-3 on hold.
5~8. UE-1 sends INVITE to the CS to establish a conference session. The AS is put on the signaling path of this call by invoking the iFC. The dialog ID between the AS and the CS is D3.
9. The CS coordinates with MRFP to allocate conference resources.
10~17. The CS sends 200 OK and receives ACK from UE-1.
18~23. UE-1 sends REFER to UE-2 with Refer-To set to the address of the CS. The AS sends “202 Accepted” and terminates the REFER in order to perform REFER interworking.
24~29. The AS optionally sends NOTIFY to UE-1 to indicate that the AS is processing the REFER request.
30. The AS sends an empty INVITE to the CS (dialog D4) to join the conference created by UE-1.
31. The CS coordinates with MRFP to allocate more resources.
32. The CS sends 200 OK to the AS. This response includes an SDP offer (O1) based on the conference information.
33~34. The AS sends re-INVITE with SDP offer (O1) to UE-2 on the existing dialog (D1) to update the session to conference session.
35~36. UE-2 sends 200 OK to the AS to acknowledge the re-INVITE. This response contains an SDP answer (A1) based on the SDP offer (O1) received.
37. The AS sends ACK with SDP answer (A1) to the CS to reply to the SDP offer received in Step 32. End-to-End offer/answer exchange between the CS and UE-2 is completed.
38~39. The AS also sends ACK to UE-2 to acknowledge the 200 OK from UE-2.
40~45. The AS sends NOTIFY to UE-1 to indicate that it has finished action required by the REFER request.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12.3 Service Procedures for 3WC 59 12 Three-Way Conferencing
46~51. UE-1 sends BYE to terminate the dialog used for communication between itself and UE-2.
52. In parallel to step 18~51, UE-1 follows the similar procedures to add UE-3 into the conference.
12.3 Service Procedures for 3WC
12.3.1 UE
The UE shall follow the procedures specified in [MMD Part-4] with the additions in this section.
When a UE is participating in two or more SIP sessions and wants to join together two or more of these active sessions to a three-way session, the UE shall perform the following steps:
1. for each of the active sessions, apply the procedure for call hold as described in Clause 6 of this specification;
2. create a conference at the conference focus by sending an INVITE request with the conference factory URI for the three-way session towards the conference focus, as described in subclause 5.3.1.3.2 of [X.S0029];
3. for each of the active sessions, that are requested to be joined to the three-way session, invite the other user to the conference by generating an REFER request to the remote UE as described in subclause 5.3.1.5.2 of [X.S0029] and sending the REFER request to the remote UE within the existing dialog;
4. for each of the active sessions, release the active session with the other users, by applying the procedures for session release in accordance with [MMD Part-4], after a NOTIFY request has been received from the other user, indicating that the other user has successfully joined the three-way session, i.e. including:
a. a body of content-type "message/sipfrag" that indicates a "200 OK" response; and,
b. a Subscription-State header set to the value "terminated".
12.3.2 AS
The AS shall follow the procedures specified in [MMD Part-4] with the additions in this section.
The AS performs 3WC either without 3PCC or with 3PCC.
12.3.2.1 AS Procedures without 3PCC
If 3WC without 3PCC is applied, the AS (acting as a conference server) shall follow the procedures specified in Section 5.3.2 and 6.3.2 of [X.S0029].
12.3.2.2 AS Procedures with 3PCC
If 3WC with 3PCC is applied, the AS serving the controlling UE shall first check that a valid REFER request is received on the dialog to be transferred:
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
12 Three-Way Conferencing 60 12.3 Service Procedures for 3WC
The Request-URI in the REFER request is targeted to the same UE instance (remote UE) that is involved in the dialog; and,
The Refer-To header in the REFER request contains an URI so that the method constructed from the URI is equal to an INVITE request to the Conference focus.
Otherwise, the AS may, depending on the operator policy:
Reject the REFER request; or,
Handle the REFER request with another service; or,
Proxy the REFER request on.
If the AS determines that the REFER request is valid for 3PCC, the AS shall follow procedures specified in [MMD Part-4] for 3PCC as an initiating B2BUA:
terminate the REFER request from the controlling UE by sending 202 Accepted response;
send a NOTIFY (100 Trying);
send an INVITE request to the conference server without SDP content body based on the Refer-To header in the REFER request;
Upon receiving a reliable response (reliable 18x response or 200 OK response) from the conference server, due to the AS generated INVITE request triggered by a REFER request, the AS shall generate a re-INVITE request to the remote UE identified in that REFER request. The re-INVITE shall include the media information in the SDP offer that matches what was received from the conference server. The re-INVITE request is sent to the remote UE over the existing dialog.
Upon receiving a reliable response (200 OK) to the re-INVITE request from the remote UE with SDP answer information in the message body, the AS shall include the media information in the SDP answer into the next eligible request toward the conference server as an answer to the original SDP offer received. The next eligible request may be one of the following:
PRACK request for a reliable 18x provisional response; or,
ACK request for 200 OK response.
Upon successful completion of the 3PCC procedure between the conference server and the remote UE, the AS shall send a NOTIFY request to the controlling UE to indicate that the call transfer has been completed based on the REFER request.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
13.1 Service Description 61 13 Message Waiting Indication
13 Message Waiting Indication
13.1 Service Description Message Waiting Indication (MWI) service enables the network to indicate to the served user about the status of a message account, e.g., voicemail waiting.
13.2 Call Flows
13.2.1 MWI with message-summary event package
UE-1 P-CSCF S-CSCF AS1. SUBSCRIBE (message-
summary)
4. 200 OK (SUBSCRIBE)5. 200 OK (SUBSCRIBE)
6. 200 OK (SUBSCRIBE) 7. NOTIFY (message-summary)
10. 200 OK (NOTIFY)11. 200 OK (NOTIFY)
12. 200 OK (NOTIFY)
2. SUBSCRIBE (message-summary) 3. SUBSCRIBE (message-
summary)
8. NOTIFY (message-summary)9. NOTIFY (message-
summary)
13. New message arrivals
14. NOTIFY (message-summary)
17. 200 OK (NOTIFY)18. 200 OK (NOTIFY)
19. 200 OK (NOTIFY)
15. NOTIFY (message-summary)16. NOTIFY (message-
summary)
Figure 18 MWI with message-summary event package
1~6. UE-1 sends SUBSCRIBE to the Message AS to subscribe to message-summary event; the AS accepts the subscription and returns 200 OK.
7~12. The AS sends NOTIFY with message-summary to notify UE-1 of the message status; UE-1 acknowledges with 200 OK.
13. New message arrives at the AS and triggers another notification.
14~19. The AS sends NOTIFY with message-summary to notify UE-1 of the message status; UE-1 acknowledges with 200 OK.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
13 Message Waiting Indication 62 13.3 Service Procedures for MWI
13.2.2 MWI with SMS
Figure 19 MWI with encapsulated SMS
1~6. UE-1 registers for IMS services and the SMS-GW is notified of the UE’s registration status as described in [MMD Part-4].
7. At any time, the legacy voice mail server can send SMS through the SMS-GW to notify the user of voice mailbox event.
8~13. If UE-1 is registered on IMS as shown above, the SMS-GW sends MESSAGE with encapsulated SMS to UE-1; UE-1 acknowledges with 200 OK.
14. New message arrives at the voice mail server and triggers another notification.
15. Legacy voice mail server sends SMS to notify the user of new message arrival. The SMS message is routed to SMS-GW for delivering to UE-1.
16~21. The SMS-GW sends MESSAGE with encapsulated SMS to UE-1; UE-1 acknowledges with 200 OK.
13.3 Service Procedures for MWI
13.3.1 UE
The procedures specified in [MMD Part-4] shall apply with the additions in this section.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
13.3 Service Procedures for MWI 63 13 Message Waiting Indication
When the subscriber user agent intends to subscribe for status information changes of a message account, it shall generate a SUBSCRIBE request in accordance with [RFC3265] and [RFC3842] and in alignment with the procedures described in [MMD Part-4].
Depending on the service provisioning the UE will address the SUBSCRIBE request either to one of the subscriber's public user identities or to the public service identity of the message account.
The subscriber's UE shall implement the "application/simple-message-summary" content type as described in [RFC3842].
As an alternative notification mechanism, the MWI may be provided using MESSAGE method [RFC3428] with an encapsulated SMS message. If this approach is chosen, the UE shall implement the SMS-over-IMS receiver role as specified in [X.S0048].
13.3.2 AS
If the MWI service is provided using the mechanism described in [RFC3842], then the procedures specified in [MMD Part-4] shall apply with the additions in this subsection. Otherwise, there are no MWI specific procedures required at the AS.
When the Application Server receives a SUBSCRIBE request for the "message-summary" event package, the Application Server shall identify the message account for which status information is requested. The message account may be identified by either a public service identity or any of the subscriber's public user identities. The AS shall then attempt to verify the identity of the source of the SUBSCRIBE request and perform authorization according to [MMD Part-4].
In case of successful subscription, the AS shall generate a response to the SUBSCRIBE request and notifications in accordance with [RFC3265] and [RFC3842].
As an alternative notification mechanism, the MWI may be provided using MESSAGE method with an encapsulated SMS message.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
14 DTMF Support 64 14.1 Service Description
14 DTMF Support
14.1 Service Description DTMF digits enable various applications such as voice mail checking, banking, automated customer support etc, where user input is required to access a service after the voice call is established.
DTMF digits are carried in a RTP stream and is negotiated using SDP. The RTP Payload format for DTMF Digits is specified in RFC 2833.
14.2 Call Flows A sample SDP offer below shows how to specify support for DTMF in the SIP message. In this example, the support for DTMF is indicated using “telephone-event” payload type in addition to the audio codec (EVRC) for the session.
v=0 o=- 289083124 289083124 IN IP4 10.20.1.100 s=- t=0 0 c=IN IP4 10.20.1.100 m=audio 30000 RTP/AVP 98 97 a=rtpmap:98 EVRC/8000 a=ptime:60 a=rtpmap:97 telephone-event/8000
14.3 Service Procedures for DTMF
14.3.1 UE
The UE shall follow the procedures of [MMD Part-4] for initiating a call and for including the MIME subtype “telephone-event” in the SDP offer to indicate support for DTMF payloads.
14.3.2 AS
The AS shall follow the procedures of [MMD Part-4].
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
15.1 Service Description 65 15 User Provisioning
15 User Provisioning
15.1 Service Description User provisioning service allows the end user to update preferences in the network. For example, the user can activate or deactivate call forwarding services through user provisioning procedures.
15.2 Call Flows
15.2.1 User provisioning using DTMF
Figure 20 User provisioning with DTMF
1~9. UE-1 establishes a call with the provisioning AS following normal call setup procedure. Both UE-1 and the AS indicates support for DTMF.
10~15. After the provisioning using voice prompt and DTMF, UE-1 sends BYE to terminate the call with the AS.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
15 User Provisioning 66 15.3 Service Procedures for user provisioning using feature code
15.2.2 User provisioning using feature code
Figure 21 User provisioning using feature code
1~9. UE-1 establishes a call with the provisioning AS following normal call setup procedure. UE-1 sends the provisioning information as part of the Request URI.
10. The AS performs feature activation or deactivation based on the information received from the UE. It can also announce the provisioning result to UE-1.
11~16. After the provisioning is completed, UE-1 sends BYE to terminate the call with the AS.
15.3 Service Procedures for user provisioning using feature code
15.3.1 UE
When performing user provisioning using feature code, the UE shall create a Tel URI [RFC3966] or a SIP URI which is an equivalent to the TEL URI, with:
a. a local number, set to either the concatenation of feature code and the number to be provisioned or the feature code alone if no number information needs to be provided for the service; and,
b. a “phone-context” parameter, set to the home network domain name.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
15.4 Service Procedures for user provisioning using DTMF 67 15 User Provisioning
The UE shall construct and initiate an appropriate INVITE according to [MMD Part-4] with the Request URI set to the URI created above.
15.3.2 AS
Upon receiving an INVITE request containing a Tel URI or a SIP URI equivalent to the TEL URI, including a “phone-context” parameter equal to the home network domain name and a local number representing a feature code or a concatenation of feature code and number to be provisioned, the AS shall:
a. terminate the INVITE request following the procedures specified for AS acting as a terminating UA in [MMD Part-4]; and,
b. perform service activation, deactivation, or modification based on the feature code information received.
Based on the outcome of the service provisioning, the AS may play appropriate network announcement to notify the user of the provisioning result.
15.4 Service Procedures for user provisioning using DTMF This procedure assumes that the AS is the provisioning network entity and supports RFC2833 [RFC2833].
15.4.1 UE
The UE shall follow the procedures of MMD [MMD Part-4] for initiating a call and for including the MIME subtype “telephone-event” in the SDP offer to indicate support for DTMF payloads.
15.4.2 AS
The AS shall follow the procedures of MMD [MMD Part-4] for terminating a call. It shall also include the MIME subtype “telephone-event” in the SDP answer to indicate support for DTMF payloads as described in [RFC2833].
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16 Customized Ring Back Tones 68 16.1 Service Description
16 Customized Ring Back Tones
16.1 Service Description Customized Ring Back Tones (CRBT) service allows the terminating user to play customized music or other pre-recorded messages toward the originating user.
16.2 Call Flows If both calling UE and AS support early session, then early session call flow in section 16.2.1 which is based on [RFC3959] may be used. Otherwise, the non-early-session call flow in 16.2.2 applies.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16.2 Call Flows 69 16 Customized Ring Back Tones
16.2.1 Early-session case
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16 Customized Ring Back Tones 70 16.2 Call Flows
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16.2 Call Flows 71 16 Customized Ring Back Tones
Figure 22 CRBT Call Flow
1~2. UE-2 sends INVITE with an SDP OFFER (O1) to establish a call with UE-1. The INVITE is routed to the AS due to initial Filter Criteria on the S-CSCF. UE2 includes the early-session option tag in its Supported header field of the SIP INVITE.
3~5. The AS sends INVITE with an SDP OFFER (O1) to the UE-1.
6~11 . The AS determines that UE-1 has CRBT service and requests resources from MRFP. The AS determines that UE-2 supports early session and sends a SIP 183 to UE-2 with early session. Early session contains an SDP OFFER (RBT-O) which helps to establish the CRBT media between the MRFP and UE-2. UE-2 acknowledges SIP 183 with an SDP ANSWER (RBT-A) in early session, and AS plays RBT to UE2. Based on operator policy, Steps 6~11 can happen right after Step 2 before the INVITE is forwarded to UE-1.
12~14. UE-1 sends a SIP 18x with an SDP answer (A1), the response first reaches the AS.
15~16. The AS forwards the response with SDP answer (A1) to UE-2.
17~18. UE-2 acknowledges the reliable provisional response received in Step 16.
19~21. The AS acknowledges the reliable provisional response received in Step 14. This acknowledgement occurs after receiving the reliable provisional response (Step 14) or after receiving the PRACK (Step 18).
22~24. UE1 sends a 200 OK in response to the PRACK (Step 21).
25~26. The AS sends a 200 OK in response to PRACK (Step 18). The 200 OK occurs after receiving the PRACK (Step 18) or after receiving the 200 OK (Step 24).
27~36. The UE1 answers the call. UE-1 sends 200 OK to the AS, and AS stop RBT which is established by early session.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16 Customized Ring Back Tones 72 16.2 Call Flows
16.2.2 Non Early-session case
Figure 23 CRBT Call Flow
1~2. UE-2 sends INVITE with an SDP offer (O1) to establish a call with UE-1. The INVITE is routed through the AS due to initial filter triggers on the S-CSCF.
3~5. The AS forwards the original INVITE to UE-1.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16.3 Service Procedures for CRBT 73 16 Customized Ring Back Tones
6~8. UE-1 sends “180 Ringing” with an SDP answer (A1) for an early dialog (D1), the response first reaches the AS.
9. The AS request resources from MRFP and creates CRBT answer (A2). Based on operator policy, Steps 9~15 can happen right after Step 2 before the INVITE is forwarded to UE-1.
10~11. The AS generates a reliable “183 Session Progress” response to UE-2 as if this is a response from a forked INVITE, which establishes an early dialog (D2). Using “183 Session Progress” avoids triggering local RBT at UE-2. This response message contains the SDP answer (A2) which helps to establish the CRBT media path between the MRFP and UE-2.
12~13. UE-2 acknowledges the reliable provisional response.
14~15. The AS sends 200OK to acknowledge PRACK from UE-2.
16~17. The AS changes the “180 Ringing” response received from UE-1 to “183 Session Progress” and forwards the response with the same answer (A1) to UE-2 and establishes early dialog (D1). Based on operator policy, Steps 16 ~19 and Steps 26~27 can also be omitted if the AS chooses to store the answer (A1) from UE-1 and not to send provisional response immediately. UE-2 still saves both SDP answers A1 and A2 since it has no knowledge which answer will be confirmed finally.
18~19. UE-2 acknowledges the reliable provisional response message.
20~25. The AS acknowledges the reliable provisional response from UE-1.
28~30. The user at UE-1 finally answers the call. UE-1 sends 200 OK and the response reaches the AS first.
31. The AS coordinates with the MRFP to stop playing RBT.
32~33. The AS forwards the 200 OK to UE-2 to confirm the early dialog (D1). If the AS has not sent the answer (A1) from UE-1 to UE-2 in step 16, the AS includes the answer (A1) in this 200 OK message and confirms dialog (D1).
34~38. UE-2 acknowledges the confirmed dialog (D1). The call is now established between UE-1 and UE-2 based on SDP offer (O1) and SDP answer (A1). The early dialog (D2) set up by the “183 Session Progress” for CRBT has no final response and automatically times out.
16.3 Service Procedures for CRBT
16.3.1 UE
The UE shall follow the procedures in [MMD Part-4] for session initiation and termination.
If the originating UE supports the early session mechanism specified in [RFC3959], then the originating UE may include the “early-session” option tag in the Supported header as described in [RFC3959] in the INVITE request for session initiation.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16 Customized Ring Back Tones 74 16.3 Service Procedures for CRBT
16.3.2 AS
The procedures specified in [MMD Part-4] for AS acting as a routing B2BUA apply with additions in this section.
The AS shall follow the procedures in Section 16.3.2.1 to provide CRBT service unless the AS supports the early session mechanism specified in [RFC3959]. If the initial INVITE destined to served user includes a Supported header with “early-session” option tag and the AS supports “early-session mechanism [RFC3959], then the AS may follow the procedures in Section 16.3.2.2 to provide CRBT service.
16.3.2.1 AS procedures with no early-session
Upon receiving an initial INVITE request destined to the served user,
The AS shall contact the MRFP to request CRBT resource, send a reliable 183 (Session Progress) response to the originating UE, and instruct the MRFP to start CRBT media. The 183 provisional response shall:
— include a P-Asserted-Identity header containing the public user identity of the served user;
— include a To header containing the same URI as received in the INVITE request but with a to-tag locally generated by the AS;
— include an SDP answer to the SDP offer received in the INVITE request. The SDP answer shall be the same as the SDP returned by the MRFP.
The AS shall forward the initial INVITE request to the served user.
The AS may send the 183 reliable provisional response with MRFP SDP information either:
After receiving the incoming INVITE request; or,
After receiving the first reliable provisional response from the served UE.
Upon receiving a reliable provisional response from a served UE containing an SDP answer to the original INVITE, the AS:
may send the provisional response to the originating UE reliably after changing the Status-Line to 183 Session Progress. The AS shall not change the to-tag of the received provisional response,
shall respond to the received provisional response by sending a PRACK as defined in [RFC3262] to the served UE;
shall save the SDP content contained in the reliable provisional response. If forking has occurred toward the served user, the AS shall save multiple SDP answers from several different UEs.
shall associate the saved SDP answer with the early dialog that the reliable provisional response established.
Upon receiving a 200 OK response from a served UE indicating that the served user has answered the call,
the AS shall instruct the MRFP to stop CRBT media.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16.3 Service Procedures for CRBT 75 16 Customized Ring Back Tones
The AS shall generate and forward the 200 OK response to the originating UE.
— If the AS has saved the SDP answer received on the same dialog confirmed by the 200 OK response and if the AS has not forwarded the SDP answer to the originating UE, the AS shall include the saved SDP answer in the body of the 200 OK response.
— If the AS has not saved an SDP answer on the same dialog confirmed by the 200 OK response the AS shall include the SDP in th received 200 OK response in the 200 OK response to the originating UE.
— The to-tag of the 200 OK response shall be the same as the to-tag in the received 200 OK response.
16.3.2.2 AS procedures with early-session
Upon receiving an initial INVITE request destined to the served user, the AS shall forward the initial INVITE request to the served user.
The AS shall contact the MRF to request CRBT resources either upon receiving the initial INVITE request or upon receiving a 18x response from the served user. If the AS requested CRBT resources upon receiving the initial INVITE request, the AS upon receiving the MRF SDP offer shall send a reliable 183 (Session Progress) response to the originating UE containing an early-session offer. Then the reliable 183 (Session Progress) provisional response shall:
include a P-Asserted-Identity header containing the public user identity of the served user. Privacy rules shall be followed if applicable;
include a To header containing the same URI as received in the INVITE request but with a to-tag locally generated by the AS;
include a Require header with option tag “early-session”.
include a Content-Disposition header with the value “early-session”.
include an early-session SDP offer that is the same as the SDP returned by the MRF.
If the AS sends the reliable 183 (Session Progress) provisional response after receiving the first reliable 180 (Ringing) provisional response with SDP answer from the served UE, the AS shall
c. If CRBT resources have not been previously requested and the 18x provisional response contains an SDP answer to the initial INVITE, the AS shall contact the MRF to request CRBT resources. The AS upon receiving the MRF SDP offer shall send a reliable 18x response to the originating UE containing an early-session offer and a session answer. The 18x response shall:
— include a P-Asserted-Identity header containing the public user identity of the served UE. Privacy rules shall be followed if applicable;
— include a Require header with option tag “early-session”;
— include a Content-Type with the value “multipart/mixed”. Within the multi-part body, the following parts shall be included;
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16 Customized Ring Back Tones 76 16.3 Service Procedures for CRBT
one part with a Content-Disposition header with the value “early-session” and an SDP offer. The SDP offer shall be the same as the SDP offer returned by the MRF.
one part with a Content-Disposition header with the value “session” and an SDP answer. The SDP answer shall be the same as that received from the served UE in the provisional response.
d. If CRBT resources have not been previously requested and the 18x provisional response does not contains an SDP answer to the initial INVITE, the AS shall contact the MRF to request CRBT resources. The AS upon receiving the MRF SDP offer shall send a reliable 18x response to the originating UE containing an early-session offer. The 18x response shall:
— include a P-Asserted-Identity header containing the public user identity of the served user;
— include a To header containing the same URI as received in the INVITE request but with a to-tag locally generated by the AS;
— include a Require header with option tag “early-session”;
— include a Content-Disposition header with the value “early-session”;
— include an early-session SDP offer that is the same as the SDP returned by the MRF.
e. If CRBT resources have been previously requested and the 18x provisional response contains an SDP answer to the initial INVITE the AS shall send a reliable 18x (Session Progress) response to the originating UE containing a session answer. The SDP answer shall be the same as that received from the served UE in the 18x response.
f. If CRBT resources have been previously requested and the 18x provisional response does not contain an SDP answer the AS shall forward the 18x response to the originating UE.
Upon receiving the early-session SDP answer from the originating UE the AS shall send the SDP answer to the MRF and instruct the MRF to start playing CRBT media.
Upon receiving a 200 OK response from the served UE indicating that the served user has answered the call, the AS shall:
— instruct the MRFP to stop playing CRBT media
— forward the 200 OK response to the originating UE.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
16.3 Service Procedures for CRBT 77 16 Customized Ring Back Tones
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
17 Directory Assistance 78 17.1 Service Description
17 Directory Assistance
17.1 Service Description Directory Assistance (411) allows a customer to call 411 Directory Assistance, to interact with the attendant to get the desired number and to then have the call completed by the attendant.
17.2 Call Flows
Figure 24 Directory Assistance
1~3. UE-1 sends INVITE to request a call for DA service. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
4. The AS determines that the call is intended for DA service.
5~6. The AS forwards the INVITE to the attendant for DA service at UE-2.
7. UE-1 and UE-2 follows normal call setup procedure to establish the call.
8. The attendant at UE-2 transfers the call from UE-1 to UE-3 based on the DA service requested.
17.3 Service Procedures for DA
17.3.1 UE
The UE shall create a Tel URI [RFC3966] or a SIP URI equivalent to the Tel URI as described in [RFC3261] with:
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
17.3 Service Procedures for DA 79 17 Directory Assistance
a. a local number set to the directory assistance number; and,
b. a “phone-context” parameter set to the home network domain name.
When invoking the DA service, the UE shall construct and initiate an INVITE according to [MMD Part-4] with the Request URI set to the Tel URI created above.
17.3.2 AS
Upon receiving an INVITE request containing a Tel URI or a SIP URI equivalent to a Tel URI, including a local number and a “phone-context” parameter equal to the home network domain name, the AS shall:
a. map the local number in the received Request URI into the public user identity of the DA service attendant ; and,
b. replace the Request URI within the received INVITE with the mapping result.
The AS shall then process and forward the new INVITE according to [MMD Part-4].
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
18 Voice Mail Deposit/Retrieval 80 18.1 Service Description
18 Voice Mail Deposit/Retrieval
18.1 Service Description Voice Mail Deposit (VMD) service allows a user to have his/her unanswered calls deposited in a voice message system (VMS).
Voice Message Retrieval (VMR) service allows a user to retrieve messages from a voice message system (VMS).
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
18.2 Call Flows 81 18 Voice Mail Deposit/Retrieval
18.2 Call Flows
18.2.1 Voice mail deposit
Figure 25 Voicemail Deposit
1~5. UE-3 sends INVITE to UE-1 to establish a call. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
6~11. UE-1 sends “486 Busy Here” to indicate that it is busy. This response is intercepted by the AS and acknowledged with ACK.
12. The AS executes voice mail deposit service on behalf of UE-1.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
18 Voice Mail Deposit/Retrieval 82 18.2 Call Flows
13~14. The AS optionally sends “181 Call is Being Forwarded” to notify UE-3 that the call is being forwarded.
15. The AS forwards the INVITE to the Voice Mail Server.
16~30. UE-3 and the VMS exchange subsequent messages to establish a call to deposit voice message.
18.2.2 Voice mail retrieval
Figure 26 Voice mail retrieval
1~3. UE-1 sends INVITE to request a call for VMS. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
4. The AS determines that the call is intended for VMS.
5. The AS forwards the INVITE to the VMS.
6~25. UE-1 and the VMS follow normal call setup procedure to establish the call for voice mail retrieval.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
18.3 Service Procedures for VMD and VMR 83 18 Voice Mail Deposit/Retrieval
18.3 Service Procedures for VMD and VMR
18.3.1 UE
In order to support VMD service, the UE shall be able to initiate or terminate sessions in accordance to call forwarding procedures described in Section 9.
In order to support VMR service, the UE shall create a Tel URI [RFC3966] or a SIP URI equivalent to the Tel URI as described in [RFC3261] with:
a. a local number, set to voice mail service number; and,
b. a “phone-context” parameter, set to the home network domain name.
When invoking the VMR service, the UE shall construct and initiate an appropriate INVITE according to [MMD Part-4] with the Request URI set to the Tel URI created above.
18.3.2 AS
In order to support VMD service, the AS shall be able to perform call forwarding procedures as described in Section 9. When forwarding a call, the AS shall set the Request URI to the public service identity of the VMS.
For VMR service, upon receiving an INVITE request containing a Tel URI or a SIP URI equivalent to a Tel URI, including a local number and a “phone-context” parameter equal to the home network domain name, the AS shall:
a. map the local number in the received Request URI into the public user identity of the intended destination; and,
b. replace the Request URI within the received INVITE with the mapping result.
The AS shall then process and forward the new INVITE according to [MMD Part-4].
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19 Flexible Alerting 84 19.1 Service Description
19 Flexible Alerting
19.1 Service Description Flexible Alerting (FA) service causes a call to a Pilot Identity to branch into several legs to alert several termination addresses (group members) simultaneously. The first device to be answered is connected to the originating user. The other call legs are abandoned.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19.2 Call Flows 85 19 Flexible Alerting
19.2 Call Flows
19.2.1 Flexible Alerting
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19 Flexible Alerting 86 19.2 Call Flows
Figure 27 Flexible Alerting
1~2. UE-3 sends an INVITE with the Request-URI set to the Flexible Alerting group’s value (this value can be a tel-URI or SIP-URI), attempting to establish a call to the group. The INVITE is forwarded to an AS that supports the Flexible Alerting group. For this scenario, it is assumed that the Flexible Alerting group has two member subscribers, each of which is being served by the same S-CSCF.
3. The AS executes the FA service.
4~6. The AS sends the INVITE contains an SDP offer to the first member of the FA group, UE-1.
7~9. UE-1 is alerted following the normal call setup procedure. UE-1 sends a 180 response to the AS containing an SDP answer.
10~12. The AS acknowledges receipt of the 180 response by sending a PRACK to UE-1.
13~15. UE-1 sends a 200 OK in response to the PRACK sent in Step 12.
16~21. Upon receipt of the first 180 response (see Step 9), the AS sends a “180 Ringing” back to UE-3 that has no SDP information.
22~24. In parallel to step 4~15, the AS also sends the INVITE to the second member of the FA group, UE-2.
25~27. UE-2 is alerted following the normal call setup procedure. UE-2 sends a 180 response to the AS containing an SDP answer.
28~30. The AS acknowledges receipt of the 180 response by sending a PRACK to UE-2.
31~33. UE-2 sends a 200 OK in response to the PRACK sent in Step 30..
34. The subscriber eventually answers the call from UE-2.
35~37. UE-2 sends 200 OK, which is first routed to the AS.
38~43. The AS sends CANCEL to UE-1 to cancel the pending call and receives 200 OK for the CANCEL request.
44~49. UE-1 sends “487 Request Terminated” to the AS and receives ACK for acknowledgement.
50~51. In parallel to Steps 38~49, the AS forwards to UE-3 the 200 OK received from UE-2. The 200 OK includes an SDP package populated with the SDP answer received from UE-2.
52~56. UE-3 sends ACK to acknowledge the final response and the call is established between UE-2 and UE-3.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19.2 Call Flows 87 19 Flexible Alerting
19.2.2 Single User (No Redirection)
Figure 28 Single User (No Redirection)
1~2. UE-3 sends an INVITE with the Request-URI set to the Flexible Alerting group’s value (this value can be a tel-URI or SIP-URI), attempting to establish a call to the group. The INVITE is forwarded to an AS that supports the Flexible Alerting group. For this scenario, it is assumed that the Flexible Alerting group has two member subscribers, each of which is being served by the same S-CSCF.
3. The AS executes the FA service.
4~6. The AS sends the INVITE to the first member of the FA group, UE-1.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19 Flexible Alerting 88 19.2 Call Flows
7~21. UE-1 is alerted following the normal call setup procedure. Upon receipt of the first 180 response, the AS sends a “180 Ringing” back to UE-3 that has no SDP information.
22~24. In parallel to step 4~21, the AS also sends the INVITE to the second member of the FA group, UE-2.
25~30. UE-2 is busy and sends a “486 busy here” back to AS.
31. If the FA group is used for single user, AS determines that the FA group is busy.
32~37. The AS sends CANCEL to UE-1 to cancel the pending call and receives 200 OK for the CANCEL request.
38~43. UE-1 sends “487 Request Terminated” to the AS and receives ACK for acknowledgement.
44~47. AS sends “486 Busy here” to UE-3 and receives ACK for the response.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19.2 Call Flows 89 19 Flexible Alerting
19.2.3 Multiple User (No Redirection)
Figure 29 Multiple User (No Redirection)
1~2. UE-3 sends an INVITE with the Request-URI set to the Flexible Alerting group’s value (this value can be a tel-URI or SIP-URI), attempting to establish a call to the group. The INVITE is forwarded to an AS that supports the Flexible Alerting group. For this scenario, it is assumed that the Flexible Alerting group has two member subscribers, each of which is being served by the same S-CSCF.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19 Flexible Alerting 90 19.3 Service Procedures for Flexible Alerting
3. The AS executes the FA service.
4~6. The AS sends the INVITE to the first member of the FA group, UE-1.
7~21. UE-1 is alerted following the normal call setup procedure. Upon receipt of the first 180 response, the AS sends a “180 Ringing” back to UE-3 that has no SDP information.
22~24. In parallel to step 4~21, the AS also sends the INVITE to the second member of the FA group, UE-2.
25~30. UE-2 is busy and sends a “486 busy here” back to AS.
31. If the FA group is used for multiple users, AS determines that the FA group is not busy.
32~36. In parallel to step 25~30, the AS forwards to UE-3 the 200 OK received from UE-1. The 200 OK includes an SDP package populated with the Answer received from UE-1.
37~41. UE-3 sends ACK to acknowledge the final response and the call is established between UE-1 and UE-3.
42~46 On the other hand, If all of the accessible members are considered to be busy, AS sends a “486 busy here” back to UE-3 and receives ACK for the response.
19.3 Service Procedures for Flexible Alerting
19.3.1 UE
The procedures specified in [MMD Part-4] apply.
19.3.2 AS
The procedures specified in [MMD Part-4] apply with the additions in this section.
Upon receiving an incoming INVITE request destined to the pilot identity, the AS shall send the INVITE request to all the member identities within the FA group.
Upon receiving the first 18x provisional response from any of the member UEs, the AS shall:
save the SDP content received in the provisional response if an SDP body is included, associate the SDP content with the dialog identified by the received provisional response;
remove the SDP content from the provisional response;
forward the provisional response to the originating UE reliably.
Upon receiving subsequent 18x provisional responses from any of the member UEs, the AS shall:
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
19.3 Service Procedures for Flexible Alerting 91 19 Flexible Alerting
save the SDP content received in the provisional response if an SDP body is included, associate the SDP content with the dialog identified by the received provisional response;
terminate the provisional response locally;
respond to the provisional responses locally with PRACK request if the provisional response is reliable;
Upon receiving a 200 OK response to the INVITE from a member UE, the AS shall:
send CANCEL to cancel the INVITE request with all member UEs that have not sent a final response;
include an SDP body in the 200 OK response based on the following:
— if an SDP is included in the 200 OK response, use the included SDP information.
— Otherwise, if an SDP body has been saved from a previous reliable provisional response and is associated with the same dialog identified by the 200 OK response, use the saved SDP;
send the 200 OK response for the INVITE to the originating UE.
For a single-user FA group, if the AS receives 486 Busy Here response from any of the member UEs before receiving 2xx responses, the AS shall:
send CANCEL to cancel the INVITE request with all member UEs that have not sent a final response;
send the 486 Busy Here response to the originating UE.
For a multiple-user FA group, if the AS receives 486 Busy Here responses from all the member UEs, the AS shall send a 486 Busy Here response to the originating UE.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
20 Outbound/Inbound Call Restrictions 92 20.1 Service Description
20 Outbound/Inbound Call Restrictions
20.1 Service Description Outbound Call Restrictions/Dialing Permissions refers to the type of calls the user is allowed to originate. Some examples are provided as follows.
Local Calls Only
Selected Leading Digits of Directory Number (e.g., NPA-NXX for NANP)
National Long Distance
International
Single Directory Number (“Hot Line”)
Toll Free
Inbound Call Restrictions refers to the ability to restrict the type of calls that a user is allowed to receive.
20.2 Call Flows
20.2.1 Outbound Call Restriction
Figure 30 Outbound Call Restriction
1~3. UE-1 sends INVITE to other end points to establish a call. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
20.2 Call Flows 93 20 Outbound/Inbound Call Restrictions
4. The AS determines that UE-1 is subject to OCR service and the INVITE matches restriction criteria.
5~7. The AS sends “603 Declined” to UE-1 to reject the call.
8~10. UE-1 sends ACK to acknowledge the final response.
20.2.2 Inbound Call Restriction
UE-1 P-CSCF S-CSCF AS
3. inbound Call Restricted
7. ACK
6. ACK
1. INVITE
UE-2
2. INVITE
4. 603 Declined
5. 603 Declined
Figure 31 Inbound Call Restriction
1~2. UE-2 sends INVITE to UE-1 to establish a call. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
3. The AS determines that UE-1 has ICR service and the INVITE matches rejection criteria.
4~5. The AS sends “603 Declined” to UE-2 to reject the call.
6~7. UE-2 sends ACK to acknowledge the final response.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
20 Outbound/Inbound Call Restrictions 94 20.3 Service Procedures for OCR/ICR/ACR
20.2.3 Anonymous Call Rejection
UE-1 P-CSCF S-CSCF AS
3. Anonymous call rejected
7. ACK
6. ACK
1. INVITE
UE-2
2. INVITE
4. 433 Anonymity Disallowed
5. 433 Anonymity Disallowed
Figure 32 Anonymous Call Rejection
1~2. UE-2 sends INVITE to UE-1 to establish a call. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
3. The AS determines that UE-1 has ACR service but the INVITE contains P-Asserted-Identity header and requires Privacy levels such as “id”, “header”, “user”, and “critical”.
4~5. The AS sends “433 Anonymity Disallowed” to UE-2 to reject the call.
6~7. UE-2 sends ACK to acknowledge the final response.
20.3 Service Procedures for OCR/ICR/ACR
20.3.1 UE
There are no UE specific procedures needed for OCR/ICR/ACR services other than the procedures specified in [MMD Part-4].
20.3.2 AS
The AS shall follow the procedures specified in [MMD Part-4] with the additions in this section.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
20.3 Service Procedures for OCR/ICR/ACR 95 20 Outbound/Inbound Call Restrictions
20.3.2.1 Actions for OCR at the originating AS
When the served user is subscribed to OCR service and the attempted call is restricted by the OCR configuration information, the originating AS shall reject the outgoing call. When the AS service rejects a call, it shall send an indication to the calling user by sending a 603 (Decline) response. Additionally, before terminating the call, an announcement can be provided to the originating user.
20.3.2.2 Actions at the terminating AS
At the terminating AS, ICR shall reject incoming calls when the served users’ ICR configuration information restricts the incoming calls. When the ICR service rejects a call, it shall send an indication to the calling user by sending a 603 (Decline) response. Additionally, before terminating the call an announcement can be provided to the originating user.
At the terminating AS, the ACR service shall reject all incoming calls where the incoming SIP request:
5. includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "id" as specified in [RFC3325]; or,
6. includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "header" as specified in [RFC3323]; or,
7. includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "user" as specified in [RFC3323]; or,
8. includes the P-Asserted-Identity header field AND includes the Privacy header field indicating "critical" as specified in [RFC3323].
NOTE: In all other cases the call proceeds normally.
When the ACR service rejects a call, the ACR service shall send an indication to the calling user by sending a 433 (Anonymity Disallowed) response [RFC5079]. Additionally, before terminating the call an announcement can be provided to the originating user.
As a service option the ACR service may forward the call to a voice message service instead of rejecting the call with a 433 (Anonymity Disallowed) final response.
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
21 Short Code Dialing 96 21.1 Service Description
21 Short Code Dialing
21.1 Service Description Short Code dialing allows a user to make calls by entering a pre-defined string that is translated by the network to a valid destination address. SC is a service defined by the service provider that operates the same way for all users. For example, dialing #GAS would route the user’s call to the nearest gasoline station.
21.2 Call Flows
4. Determine Short Code service
1. INVITE (#dd)
UE-1 P-CSCF S-CSCF AS UE-2
2. INVITE (#dd)3. INVITE (#dd)
6. INVITE
5. INVITE
7. Normal call setup procedures
Media between UE-1 and UE-2
Figure 33 Short Code Dialing
1~3. UE-1 sends INVITE to request a call to a short code. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
4. The AS determines that the call is intended for a short code.
5~6. The AS forwards the INVITE to the intended destination, UE-2.
7. UE-1 and UE-2 follows normal call setup procedure to establish the call.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
21.3 Service Procedures for Short Code Dialing 97 21 Short Code Dialing
21.3 Service Procedures for Short Code Dialing
21.3.1 UE
The UE shall create a Tel URI [RFC3966] or a SIP URI equivalent to the Tel URI as described in [RFC3261] with:
a. a local number, set to the short code number; and,
b. a “phone-context” parameter, set to the home network domain name.
When invoking the Short Code Dialing service, the UE shall construct and initiate an appropriate INVITE according to [MMD Part-4] with the Request URI set to the Tel URI created above.
21.3.2 AS
Upon receiving an INVITE request containing a Tel URI or a SIP URI equivalent to a Tel URI, including a local number and a “phone-context” parameter equal to the home network domain name, the AS shall:
a. map the local number in the received Request URI into the public user identity of the intended destination; this mapping may be based on the UE’s location information; and,
b. replace the Request URI within the received INVITE with the mapping result.
The AS shall then send the INVITE to the intended destination according to [MMD Part-4].
X.S0055-0 v1.0 MMD Supplementary Services
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
22 Abbreviated Dialing 98 22.1 Service Description
22 Abbreviated Dialing
22.1 Service Description Abbreviated dialing allows a user to make calls by entering a pre-defined string that is translated by the network to a valid destination address. Abbreviated dialing service is a service defined per subscriber for use by that subscriber. For example, dialing *HOME could route a call to the subscriber’s home.
22.2 Call Flows
4. Determine Abbreviated Dialing service
1. INVITE (N11)
UE-1 P-CSCF S-CSCF AS UE-2
2. INVITE (N11)3. INVITE (N11)
6. INVITE
5. INVITE
7. Normal call setup procedures
Media between UE-1 and UE-2
Figure 34 Abbreviated Dialing
1~3. UE-1 sends INVITE to request a call to an abbreviated number. The INVITE is routed to the AS first based on initial filter trigger on UE-1’s S-CSCF.
4. The AS determines that the call is intended for an abbreviated number.
5~6. The AS forwards the INVITE to the intended destination, UE-2.
7. UE-1 and UE-2 follows normal call setup procedure to establish the call.
MMD Supplementary Services X.S0055-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
22.3 Service Procedures for Abbreviated Dialing 99 22 Abbreviated Dialing
22.3 Service Procedures for Abbreviated Dialing
22.3.1 UE
The UE shall create a Tel URI [RFC3966] or a SIP URI equivalent to the Tel URI as described in [RFC3261] with:
a. a local number, set to the abbreviated dialing number; and,
b. a “phone-context” parameter, set to the home network domain name.
When invoking the Abbreviated Dialing service, the UE shall construct and initiate an appropriate INVITE according to [MMD Part-4] with the Request URI set to the Tel URI created above.
22.3.2 AS
Upon receiving an INVITE request containing a Tel URI or a SIP URI equivalent to a Tel URI, including a local number and a “phone-context” parameter equal to the home network domain name, the AS shall:
a. map the local number in the received Request URI into the public user identity of the intended destination; and,
b. replace the Request URI within the received INVITE with the mapping result.
The AS shall then send the INVITE to the intended destination according to [MMD Part-4].
