A.1 Profiles
24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS
A.1.1 Relationship to other specifications
This annex contains a profile to the IETF specifications which are referenced by this specification, and the PICS proformas underlying profiles do not add requirements to the specifications they are proformas for.
This annex provides a profile specification according to both the current IETF specifications for SIP, SDP and other protocols (as indicated by the "RFC status" column in the tables in this annex) which are referenced by this specification and to the 3GPP specifications using SIP (as indicated by the "Profile status" column in the tables in this annex.
In the "RFC status" column the contents of the referenced specification takes precedence over the contents of the entry in the column.
In the "Profile status" column, there are a number of differences from the "RFC status" column. Where these differences occur, these differences take precedence over any requirements of the IETF specifications. Where specification concerning these requirements exists in the main body of the present document, the main body of the present document takes precedence.
Where differences occur in the "Profile status" column, the "Profile status" normally gives more strength to a "RFC status" and is not in contradiction with the "RFC status", e.g. it may change an optional "RFC status" to a mandatory "Profile status". If the "Profile status" weakens the strength of a "RFC status" then additionally this will be indicated by further textual description in the present document.
For all IETF specifications that are not referenced by this document or that are not mentioned within the 3GPP profile of SIP and SDP, the generic rules as defined by RFC 3261 [26] and in addition the rules in clauses 5 and 6 of this specification apply, e.g..
– a proxy which is built in accordance to this specification passes on any unknown method, unknown header field or unknown header field parameter after applying procedures such as filtering, insertion of P-Asserted-Identity header field, etc.;
– an UA which is built in accordance to this specification will
– handle received unknown methods in accordance to the procedures defined in RFC 3261 [26], e.g. respond with a 501 (Not Implemented) response; and
– handle unknown header fields and unknown header field parameters in accordance to the procedures defined in RFC 3261 [26], e.g. respond with a 420 (Bad Extension) if an extension identified by an option-tag in the Require header field of the received request is not supported by the UA.
A.1.2 Introduction to methodology within this profile
This subclause does not reflect dynamic conformance requirements but static ones. In particular, a condition for support of a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) but the capability of the implementation to support the parameter.
In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it does not mean that the implementation always sends it).
In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is described in the main part of this specification.
As a consequence, PDU parameter tables in this subclause are not the same as the tables describing the syntax of a PDU in the reference specification, e.g. RFC 3261 [26] tables 2 and 3. It is not rare to see a parameter which is optional in the syntax but mandatory in subclause below.
The various statii used in this subclause are in accordance with the rules in table A.1.
Table A.1: Key to status codes
|
Status code |
Status name |
Meaning |
|
m |
mandatory |
the capability shall be supported. It is a static view of the fact that the conformance requirements related to the capability in the reference specification are mandatory requirements. This does not mean that a given behaviour shall always be observed (this would be a dynamic view), but that it shall be observed when the implementation is placed in conditions where the conformance requirements from the reference specification compel it to do so. For instance, if the support for a parameter in a sent PDU is mandatory, it does not mean that it shall always be present, but that it shall be present according to the description of the behaviour in the reference specification (dynamic conformance requirement). |
|
o |
optional |
the capability may or may not be supported. It is an implementation choice. |
|
n/a |
not applicable |
it is impossible to use the capability. No answer in the support column is required. |
|
x |
prohibited (excluded) |
It is not allowed to use the capability. This is more common for a profile. |
|
c <integer> |
conditional |
the requirement on the capability ("m", "o", "n/a" or "x") depends on the support of other optional or conditional items. <integer> is the identifier of the conditional expression. |
|
o.<integer> |
qualified optional |
for mutually exclusive or selectable options from a set. <integer> is the identifier of the group of options, and the logic of selection of the options. |
|
i |
irrelevant |
capability outside the scope of the given specification. Normally, this notation should be used in a base specification ICS proforma only for transparent parameters in received PDUs. However, it may be useful in other cases, when the base specification is in fact based on another standard. |
In the context of this specification the "i" status code mandates that the implementation does not change the content of the parameter. It is an implementation option if the implementation acts upon the content of the parameter (e.g. by setting filter criteria to known or unknown parts of parameters in order to find out the route a message has to take).
It must be understood, that this 3GPP SIP profile does not list all parameters which an implementation will treat as indicated by the status code "irrelevant". In general an implementation will pass on all unknown messages, header fields and header field parameters, as long as it can perform its normal behaviour.
The following additional comments apply to the interpretation of the tables in this Annex.
NOTE 1: The tables are constructed according to the conventional rules for ICS proformas and profile tables.
NOTE 2: The notation (either directly or as part of a conditional) of "m" for the sending of a parameter and "i" for the receipt of the same parameter, may be taken as indicating that the parameter is passed on transparently, i.e. without modification. Where a conditional applies, this behaviour only applies when the conditional is met.
As an example, the profile for the MGCF is found by first referring to clause 4.1, which states "The MGCF shall provide the UA role". Profiles are divided at the top level into the two roles in table A.2, user agent and proxy. The UA role is defined in subclause A.2.1 and the proxy role is defined in subclause A.2.2. More specific roles are listed in table A.3, table A.3A, table A.3B and table A.3C. The MGCF role is item 6 in table A.3 (the MGCF role is not found in table A.3A or table A.3B). Therefore, all profile entries for the MGCF are found by searching for A.3/6 in subclause A.2.1.
As a further example, to look up support of the Reason header field, table A.4 item 38 lists the Resaon header field as a major capability that is optional for the user agent role. A subsequent search for A.4/38 in subclause A.2.1 shows that the Reason header field is optional for a user agent role to send and receive for ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, and UPDATE requests. Also, table A.162 item 48 lists the Reason header field as a major capability that is optional for the proxy role. A subsequent search for A.162/48 in subclause A.2.2 shows that, if supported, the Reason header field is mandatory to send and irrelevant to receive for ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, and UPDATE requests.
A.1.3 Roles
Table A.2: Roles
|
Item |
Roles |
Reference |
RFC status |
Profile status |
|
1 |
User agent |
[26] |
o.1 |
o.1 |
|
2 |
Proxy |
[26] |
o.1 |
o.1 |
|
o.1: It is mandatory to support exactly one of these items. |
||||
|
NOTE: For the purposes of the present document it has been chosen to keep the specification simple by the tables specifying only one role at a time. This does not preclude implementations providing two roles, but an entirely separate assessment of the tables shall be made for each role. |
||||
Table A.3: Roles specific to this profile
|
Item |
Roles |
Reference |
RFC status |
Profile status |
|
1 |
UE |
5.1 |
n/a |
o.1 |
|
1A |
UE containing UICC |
5.1 |
n/a |
c5 |
|
1B |
UE without UICC |
5.1 |
n/a |
c5 |
|
2 |
P-CSCF |
5.2 |
n/a |
o.1 |
|
2A |
P-CSCF (IMS-ALG) |
[7] |
n/a |
c6 |
|
3 |
I-CSCF |
5.3 |
n/a |
o.1 |
|
3A |
void |
|||
|
4 |
S-CSCF |
5.4 |
n/a |
o.1 |
|
5 |
BGCF |
5.6 |
n/a |
o.1 |
|
6 |
MGCF |
5.5 |
n/a |
o.1 |
|
7 |
AS |
5.7 |
n/a |
o.1 |
|
7A |
AS acting as terminating UA, or redirect server |
5.7.2 |
n/a |
c2 |
|
7B |
AS acting as originating UA |
5.7.3 |
n/a |
c2 |
|
7C |
AS acting as a SIP proxy |
5.7.4 |
n/a |
c2 |
|
7D |
AS performing 3rd party call control |
5.7.5 |
n/a |
c2 |
|
8 |
MRFC |
5.8 |
n/a |
o.1 |
|
8A |
MRB |
5.8A |
n/a |
o.1 |
|
9 |
IBCF |
5.10 |
n/a |
o.1 |
|
9A |
IBCF (THIG) |
5.10.4 |
n/a |
c4 |
|
9B |
IBCF (IMS-ALG) |
5.10.5, 5.10.7 |
n/a |
c4 |
|
9C |
IBCF (Screening of SIP signalling) |
5.10.6 |
n/a |
c4 |
|
9D |
IBCF (Privacy protection) |
5.10.8 |
n/a |
c4 |
|
10 |
Additional routeing functionality |
Annex I |
n/a |
c3 |
|
11 |
E-CSCF |
5.11 |
n/a |
o.1 |
|
11A |
E-CSCF acting as UA |
5.11.1, 5.11.2, 5.11.3 |
n/a |
c7 |
|
11B |
E-CSCF acting as a SIP Proxy |
5.11.1, 5.11.2 |
n/a |
c7 |
|
12 |
LRF |
5.12 |
n/a |
o.1 |
|
13 |
ISC gateway function |
5.13 |
n/a |
o.1 |
|
13A |
ISC gateway function (THIG) |
5.13.4 |
n/a |
c8 |
|
13B |
ISC gateway function (IMS-ALG) |
5.13.5 |
n/a |
c8 |
|
13C |
ISC gateway function (Screening of SIP signalling) |
5.13.6 |
n/a |
c8 |
|
14 |
Gm based WIC |
[8Z] |
n/a |
o.1 |
|
15 |
Transit function |
I.3 |
n/a |
c9 |
|
c2: IF A.3/7 THEN o.2 ELSE n/a – – AS. c3: IF A.3/3 OR A.3/4 OR A.3/5 OR A.3/6 OR A.3/9 THEN o ELSE o.1 – – I-CSCF, S-CSCF, BGCF, MGCF, IBCF. c4: IF A.3/9 THEN o.3 ELSE n/a – – IBCF. c5: IF A.3/1 THEN o.4 ELSE n/a – – UE. c6: IF A.3/2 THEN o ELSE n/a – – P-CSCF. c7: IF A.3/11 THEN o.5 ELSE n/a – – E-CSCF. c8: IF A.3/13 THEN o ELSE n/a – – ISC gateway function. c9 IF A.3/3 OR A.3/4 OR A.3/5 OR A.3/6 OR A.3/9 THEN o ELSE o.1 – – I-CSCF, S-CSCF, BGCF, MGCF, IBCF. o.1: It is mandatory to support exactly one of these items. o.2: It is mandatory to support at least one of these items. o.3: It is mandatory to support at least one of these items. o.4 It is mandatory to support exactly one of these items. o.5: It is mandatory to support exactly one of these items. |
||||
|
NOTE: For the purposes of the present document it has been chosen to keep the specification simple by the tables specifying only one role at a time. This does not preclude implementations providing two roles, but an entirely separate assessment of the tables shall be made for each role. |
||||
Table A.3A: Roles specific to additional capabilities
|
Item |
Roles |
Reference |
RFC status |
Profile status |
|
1 |
Presence server |
3GPP TS 24.141 [8A] |
n/a |
c1 |
|
2 |
Presence user agent |
3GPP TS 24.141 [8A] |
n/a |
c2 |
|
3 |
Resource list server |
3GPP TS 24.141 [8A] |
n/a |
c3 |
|
4 |
Watcher |
3GPP TS 24.141 [8A] |
n/a |
c4 |
|
11 |
Conference focus |
3GPP TS 24.147 [8B] |
n/a |
c11 |
|
12 |
Conference participant |
3GPP TS 24.147 [8B] |
n/a |
c6 |
|
21 |
CSI user agent |
3GPP TS 24.279 [8E] |
n/a |
c7 |
|
22 |
CSI application server |
3GPP TS 24.279 [8E] |
n/a |
c8 |
|
31 |
Messaging application server |
3GPP TS 24.247 [8F] |
n/a |
c5 |
|
32 |
Messaging list server |
3GPP TS 24.247 [8F] |
n/a |
c5 |
|
33 |
Messaging participant |
3GPP TS 24.247 [8F] |
n/a |
c2 |
|
33A |
Page-mode messaging participant |
3GPP TS 24.247 [8F] |
n/a |
c2 |
|
33B |
Session-mode messaging participant |
3GPP TS 24.247 [8F] |
n/a |
c2 |
|
34 |
Session-mode messaging intermediate node |
3GPP TS 24.247 [8F] |
n/a |
c5 |
|
50 |
Multimedia telephony service participant |
3GPP TS 24.173 [8H] |
n/a |
c2 |
|
50A |
Multimedia telephony service application server |
3GPP TS 24.173 [8H] |
n/a |
c9 |
|
51 |
Message waiting indication subscriber UA |
3GPP TS 24.606 [8I] |
n/a |
c2 |
|
52 |
Message waiting indication notifier UA |
3GPP TS 24.606 [8I] |
n/a |
c3 |
|
53 |
Advice of charge application server |
3GPP TS 24.647 [8N] |
n/a |
c8 |
|
54 |
Advice of charge UA client |
3GPP TS 24.647 [8N] |
n/a |
c2 |
|
55 |
Ut reference point XCAP server for supplementary services |
3GPP TS 24.623 [8P] |
n/a |
c3 |
|
56 |
Ut reference point XCAP client for supplementary services |
3GPP TS 24.623 [8P] |
n/a |
c2 |
|
57 |
Customized alerting tones application server |
3GPP TS 24.182 [8Q] |
n/a |
c8 |
|
58 |
Customized alerting tones UA client |
3GPP TS 24.182 [8Q] |
n/a |
c2 |
|
59 |
Customized ringing signal application server |
3GPP TS 24.183 [8R] |
n/a |
c8 |
|
60 |
Customized ringing signal UA client |
3GPP TS 24.183 [8R] |
n/a |
c2 |
|
61 |
SM-over-IP sender |
3GPP TS 24.341 [8L] |
n/a |
c2 |
|
62 |
SM-over-IP receiver |
3GPP TS 24.341 [8L] |
n/a |
c2 |
|
63 |
IP-SM-GW |
3GPP TS 24.341 [8L] |
n/a |
c1 |
|
71 |
IP-SM-GW |
3GPP TS 29.311 [15A] |
n/a |
c10 |
|
81 |
MSC Server enhanced for ICS |
3GPP TS 24.292 [8O] |
n/a |
c12 |
|
81A |
MSC server enhanced for SRVCC using SIP interface |
3GPP TS 24.237 [8M] |
n/a |
c12 |
|
81B |
MSC server enhanced for DRVCC using SIP interface |
3GPP TS 24.237 [8M] |
n/a |
c12 |
|
82 |
ICS user agent |
3GPP TS 24.292 [8O] |
n/a |
c2 |
|
83 |
SCC application server |
3GPP TS 24.292 [8O] |
n/a |
c9 |
|
84 |
EATF |
3GPP TS 24.237 [8M] |
n/a |
c12 |
|
85 |
In-dialog overlap signalling application server |
Annex N.2, Annex N.3.3 |
n/a |
c9 |
|
86 |
In-dialog overlap signalling UA client |
Annex N.2, Annex N.3.3 |
n/a |
c2 |
|
87 |
Session continuity controller UE |
3GPP TS 24.337 [8ZC] |
n/a |
c2 |
|
88 |
ATCF (proxy) |
3GPP TS 24.237 [8M] |
n/a |
c13 (note 4) |
|
89 |
ATCF (UA) |
3GPP TS 24.237 [8M] |
n/a |
c12 (note 4) |
|
91 |
Malicious communication identification application server |
3GPP TS 24.616 [8S] |
n/a |
c9 |
|
92 |
USSI UE |
3GPP TS 24.390 [8W] |
n/a |
c2 |
|
92A |
USSI UE supporting user-initiated USSD operations |
3GPP TS 24.390 [8W] |
n/a |
c17 |
|
92B |
USSI UE supporting network-initiated USSD operations |
3GPP TS 24.390 [8W] |
n/a |
c17 |
|
93 |
USSI AS |
3GPP TS 24.390 [8W] |
n/a |
c3 |
|
93A |
USSI AS supporting user-initiated USSD operations |
3GPP TS 24.390 [8W] |
n/a |
c18 |
|
93B |
USSI AS supporting network-initiated USSD operations |
3GPP TS 24.390 [8W] |
n/a |
c18 |
|
94 |
TP UE |
3GPP TS 24.103 [7G] |
n/a |
c14 |
|
95 |
eP-CSCF (P-CSCF enhanced for WebRTC) |
3GPP TS 24.371 [8Z] |
n/a |
c15 |
|
101 |
Business trunking in static mode of operation application server |
3GPP TS 24.525 [8ZA] |
n/a |
c16 |
|
102 |
MCPTT client |
3GPP TS 24.379 [8ZE] |
n/a |
c19 |
|
103 |
MCPTT server |
3GPP TS 24.379 [8ZE] |
n/a |
c20 |
|
c1: IF A.3/7A AND A.3/7B THEN o ELSE n/a – – AS acting as terminating UA, or redirect server and AS acting as originating UA. c2: IF A.3/1 THEN o ELSE n/a – – UE. c3: IF A.3/7A THEN o ELSE n/a – – AS acting as terminating UA, or redirect server. c4: IF A.3/1 OR A.3/7B THEN o ELSE n/a – – UE or AS acting as originating UA. c5: IF A.3/7D AND A.3/8 THEN o ELSE n/a – – AS performing 3rd party call control and MRFC (note 2). c6: IF A.3/1 OR A.3A/11 THEN o ELSE n/a – – UE or conference focus. c7: IF A.3/1 THEN o ELSE n/a – – UE. c8: IF A.3/7D THEN o ELSE n/a – – AS performing 3rd party call control. c9: IF A.3/7A OR A.3/7B OR A.3/7C OR A.3/7D THEN o ELSE n/a – – AS acting as terminating UA, or redirect server, AS acting as originating UA, AS acting as a SIP proxy, AS performing 3rd party call control. c10: IF A.3/7A OR A.3/7B OR A.3/7D THEN o ELSE n/a – – AS acting as terminating UA, or redirect server, AS acting as originating UA, AS performing 3rd party call control. c11: IF A.3/7D THEN o ELSE n/a – – AS performing 3rd party call control. c12: IF A.2/1 THEN o ELSE n/a – – UA. c13: IF A.2/2 THEN o ELSE n/a – – proxy. c14: IF A.3/1 OR A.3A/11 THEN o ELSE n/a – – UE or conference focus. c15: IF A.3/2A THEN o ELSE n/a – – P-CSCF (IMS-ALG). c16: IF A.3/7A OR A.3/7B THEN o ELSE n/a – – AS acting as terminating UA, or redirect server, AS acting as originating UA. c17: IF A.3A/92 THEN o.1 ELSE n/a – – USSI UE. c18: IF A.3A/93 THEN o.2 ELSE n/a – – USSI AS. c19: IF A.3/1 THEN o ELSE n/a – – UE. c20: IF A.3/7 THEN o ELSE n/a – – AS. o.1: It is mandatory to support at least one of these items. o.2: It is mandatory to support at least one of these items. |
||||
|
NOTE 1: For the purposes of the present document it has been chosen to keep the specification simple by the tables specifying only one role at a time. This does not preclude implementations providing two roles, but an entirely separate assessment of the tables shall be made for each role. NOTE 2: The functional split between the MRFC and the AS for page-mode messaging is out of scope of this document and they are assumed to be collocated. NOTE 3: A.3A/63 is an AS providing the IP-SM-GW role to support the transport level interworking defined in 3GPP TS 24.341 [8L]. A.3A/71 is an AS providing the IP-SM-GW role to support the service level interworking for messaging as defined in 3GPP TS 29.311 [15A]. NOTE 4: An ATCF shall support both the ATCF (proxy) role and the ATCF (UA) role. |
||||
Table A.3B: Roles with respect to access technology
|
Item |
Value used in P-Access-Network-Info header field |
Reference |
RFC status |
Profile status |
|
1 |
3GPP-GERAN |
[52] 4.4 |
o |
c1 |
|
2 |
3GPP-UTRAN-FDD |
[52] 4.4 |
o |
c1 |
|
3 |
3GPP-UTRAN-TDD |
[52] 4.4 |
o |
c1 |
|
4 |
3GPP2-1X |
[52] 4.4 |
o |
c1 |
|
5 |
3GPP2-1X-HRPD |
[52] 4.4 |
o |
c1 |
|
6 |
3GPP2-UMB |
[52] 4.4 |
o |
c1 |
|
7 |
3GPP-E-UTRAN-FDD |
[52] 4.4 |
o |
c1 |
|
8 |
3GPP-E-UTRAN-TDD |
[52] 4.4 |
o |
c1 |
|
8A |
3GPP-E-UTRAN-ProSe-UNR |
subclause 7.2A.4 |
n/a |
c1 |
|
8B |
3GPP-NR-FDD |
subclause 7.2A.4 |
n/a |
c1 |
|
8C |
3GPP-NR-TDD |
subclause 7.2A.4 |
n/a |
c1 |
|
8D |
3GPP-NR-U-FDD |
subclause 7.2A.4 |
n/a |
c1 |
|
8E |
3GPP-NR-U-TDD |
subclause 7.2A.4 |
n/a |
c1 |
|
8F |
3GPP-NR-ProSe-L2UNR |
subclause 7.2A.4 |
n/a |
c1 |
|
8G |
3GPP-NR-ProSe-L3UNR |
subclause 7.2A.4 |
n/a |
c1 |
|
8W |
3GPP-NR-SAT |
subclause 7.2A.4 |
n/a |
c1 |
|
9 |
3GPP2-1X-Femto |
[52] 4.4 |
o |
c1 |
|
11 |
IEEE-802.11 |
[52] 4.4 |
o |
c1 |
|
12 |
IEEE-802.11a |
[52] 4.4 |
o |
c1 |
|
13 |
IEEE-802.11b |
[52] 4.4 |
o |
c1 |
|
14 |
IEEE-802.11g |
[52] 4.4 |
o |
c1 |
|
15 |
IEEE-802.11n |
[52] 4.4 |
o |
c1 |
|
16 |
IEEE-802.11ac |
[52] 4.4 |
o |
c1 |
|
21 |
ADSL |
[52] 4.4 |
o |
c1 |
|
22 |
ADSL2 |
[52] 4.4 |
o |
c1 |
|
23 |
ADSL2+ |
[52] 4.4 |
o |
c1 |
|
24 |
RADSL |
[52] 4.4 |
o |
c1 |
|
25 |
SDSL |
[52] 4.4 |
o |
c1 |
|
26 |
HDSL |
[52] 4.4 |
o |
c1 |
|
27 |
HDSL2 |
[52] 4.4 |
o |
c1 |
|
28 |
G.SHDSL |
[52] 4.4 |
o |
c1 |
|
29 |
VDSL |
[52] 4.4 |
o |
c1 |
|
30 |
IDSL |
[52] 4.4 |
o |
c1 |
|
31 |
xDSL |
subclause 7.2A.4 |
o |
c1 |
|
41 |
DOCSIS |
[52] 4.4 |
o |
c1 |
|
51 |
DVB-RCS2 |
[52] 4.4 |
o |
c1 |
|
52 |
3GPP-UTRAN |
[52] 4.4 |
o |
c2 |
|
53 |
3GPP-E-UTRAN |
[52] 4.4 |
o |
c2 |
|
54 |
3GPP-WLAN |
[52] 4.4 |
o |
c2 |
|
55 |
3GPP-GAN |
[52] 4.4 |
o |
c2 |
|
56 |
3GPP-HSPA |
[52] 4.4 |
o |
c2 |
|
57 |
3GPP2 |
[52] 4.4 |
o |
c2 |
|
58 |
untrusted-non-3GPP-VIRTUAL-EPC |
subclause 7.2A.4 |
n/a |
c2 |
|
59 |
VIRTUAL-no-PS |
subclause 7.2A.4 |
n/a |
c2 |
|
60 |
WLAN-no-PS |
subclause 7.2A.4 |
n/a |
c2 |
|
61 |
3GPP-NR |
Subclause 7.2A.4 |
n/a |
c2 |
|
62 |
3GPP-NR-U |
Subclause 7.2A.4 |
n/a |
c2 |
|
63 |
3GPP-NR-SAT |
Subclause 7.2A.4 |
n/a |
c2 |
|
c1: If A.3/1 OR A.3/2 THEN o.1 ELSE n/a – – UE or P-CSCF. c2: If A.3/2 THEN o.1 ELSE n/a – – P-CSCF. o.1: It is mandatory to support at least one of these items. |
||||
Table A.3C: Modifying roles
|
Item |
Roles |
Reference |
RFC status |
Profile status |
|
1 |
UE performing the functions of an external attached network |
4.1 |
||
|
2 |
UE performing the functions of an external attached network operating in static mode |
4.1 |
||
|
NOTE: This table identifies areas where the behaviour is modified from that of the underlying role. Subclause 4.1 indicates which underlying roles are modified for this behaviour. |
||||
Table A.3D: Roles with respect to security mechanism
|
Item |
Security mechanism |
Reference |
RFC status |
Profile status |
|
|
1 |
IMS AKA plus IPsec ESP |
clause 4.2B.1 |
n/a |
c1 |
|
|
2 |
SIP digest plus check of IP association |
clause 4.2B.1 |
n/a |
c2 |
|
|
3 |
SIP digest plus Proxy Authentication |
clause 4.2B.1 |
n/a |
c2 |
|
|
4 |
SIP digest with TLS |
clause 4.2B.1 |
n/a |
c2 |
|
|
5 |
NASS-IMS bundled authentication |
clause 4.2B.1 |
n/a |
c2 |
|
|
6 |
GPRS-IMS-Bundled authentication |
clause 4.2B.1 |
n/a |
c2 |
|
|
7 |
Trusted node authentication |
clause 4.2B.1 |
n/a |
c3 |
|
|
8 |
SIP over TLS with client certificate authentication |
clause 4.2B.1 |
n/a |
c6 |
|
|
20 |
End-to-end media security using SDES |
clause 4.2B.2 |
o |
c5 |
|
|
20A |
End-to-access-edge media security for MSRP using TLS and certificate fingerprints |
clause 4.2B.2 |
n/a |
c4 |
|
|
20B |
End-to-access-edge media security for BFCP using TLS and certificate fingerprints |
clause 4.2B.2 |
n/a |
c4 |
|
|
20C |
End-to-access-edge media security for UDPTL using DTLS and certificate fingerprints |
clause 4.2B.2 |
n/a |
c4 |
|
|
21 |
End-to-end media security using KMS |
clause 4.2B.2 |
o |
c5 |
|
|
22 |
End-to-end media security for MSRP using TLS and KMS |
clause 4.2B.2 |
o |
c5 |
|
|
30 |
End-to-access-edge media security using SDES |
clause 4.2B.2 |
n/a |
c4 |
|
|
31 |
End-to-access-edge media security for RTP media using DTLS-SRTP and certificate fingerprints |
clause 4.2B.2 |
n/a |
c7 |
|
|
c1: IF (A.3/1A OR A.3/2 OR A.3/3 OR A.3/4) THEN m ELSE IF A.3/1B THEN o ELSE n/a – – UE containing UICC or P-CSCF or I-CSCF or S-CSCF, UE without UICC. c2: IF (A.3/1 OR A.3/2 OR A.3/3 OR A.3/4) THEN o ELSE n/a – – UE or P-CSCF or I-CSCF or S-CSCF. c3: IF (A.3/3 OR A.3/4) THEN o ELSE n/a – – I-CSCF or S-CSCF. c4: IF (A.3/1 OR A.3/2A) THEN o ELSE n/a – – UE or P-CSCF (IMS-ALG). c5: IF A.3/1 THEN o – – UE. c6: IF A.3C/2 THEN m ELSE o – – UE performing the functions of an external attached network operating in static mode. c7: IF (A.3/14 OR A.3A/95) THEN m ELSE IF (A.3/1 OR A.3/2A) THEN o ELSE n/a – – Gm based WIC or eP-CSCF or UE or P-CSCF (IMS-ALG). |
|||||