Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

A (Normative)  Profiles of IETF RFCs for 3GPP usageWord‑p. 499

A.1  ProfilesWord‑p. 499

A.1.1  Relationship to other specificationsWord‑p. 499

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 and in addition the rules in clause 5 and clause 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, 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, 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.
Up

A.1.2  Introduction to methodology within this profileWord‑p. 499

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 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.
Status code Status name Meaning
mmandatorythe 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).
ooptionalthe capability may or may not be supported. It is an implementation choice.
n/anot applicableit is impossible to use the capability. No answer in the support column is required.
xprohibited (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 optionalfor 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 irrelevantcapability 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.
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 clause A.2.1 and the proxy role is defined in clause 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 clause 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 clause 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 clause 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.
Up

A.1.3  RolesWord‑p. 501

Item Roles Reference RFC status Profile status
1User agent RFC 3261o.1o.1
2Proxy RFC 3261o.1o.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.
Item Roles Reference RFC status Profile status
1UE5.1n/ao.1
1AUE containing UICC5.1n/ac5
1BUE without UICC5.1n/ac5
2P-CSCF5.2n/ao.1
2AP-CSCF (IMS-ALG)[7]n/ac6
3I-CSCF5.3n/ao.1
3Avoid
4S-CSCF5.4n/ao.1
5BGCF5.6n/ao.1
6MGCF5.5n/ao.1
7AS5.7n/ao.1
7AAS acting as terminating UA, or redirect server5.7.2n/ac2
7BAS acting as originating UA5.7.3n/ac2
7CAS acting as a SIP proxy5.7.4n/ac2
7DAS performing 3rd party call control5.7.5n/ac2
8MRFC5.8n/ao.1
8AMRB5.8An/ao.1
9IBCF5.10n/ao.1
9AIBCF (THIG)5.10.4n/ac4
9BIBCF (IMS-ALG)5.10.5, 5.10.7n/ac4
9CIBCF (Screening of SIP signalling)5.10.6n/ac4
9DIBCF (Privacy protection)5.10.8n/ac4
10Additional routeing functionality Annex In/ac3
11E-CSCF5.11n/ao.1
11AE-CSCF acting as UA5.11.1, 5.11.2, 5.11.3n/ac7v
11BE-CSCF acting as a SIP Proxy5.11.1, 5.11.2n/a c7
12LRF5.12n/ao.1v
13ISC gateway function5.13n/ao.1
13AISC gateway function (THIG)5.13.4n/ac8
13BISC gateway function (IMS-ALG)5.13.5n/ac8
13CISC gateway function (Screening of SIP signalling)5.13.6n/ac8
14Gm based WIC[8Z]n/ao.1
15Transit functionI.3n/ac9
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.
Item Roles Reference RFC status Profile status
1Presence serverTS 24.141n/ac1
2Presence user agentTS 24.141n/ac2
3Resource list serverTS 24.141n/ac3
4WatcherTS 24.141n/ac4
11Conference focusTS 24.147n/ac11
12Conference participantTS 24.147n/ac6
21CSI user agentTS 24.279n/ac7
22CSI application serverTS 24.279n/ac8
31Messaging application serverTS 24.247n/ac5
32Messaging list serverTS 24.247n/ac5
33Messaging participantTS 24.247n/ac2
33APage-mode messaging participantTS 24.247n/ac2
33BSession-mode messaging participantTS 24.247n/ac2
34Session-mode messaging intermediate nodeTS 24.247n/ac5
50Multimedia telephony service participantTS 24.173n/ac2
50AMultimedia telephony service application serverTS 24.173n/ac9
51Message waiting indication subscriber UATS 24.606n/ac2
52Message waiting indication notifier UATS 24.606n/ac3
53Advice of charge application serverTS 24.647n/ac8
54Advice of charge UA clientTS 24.647n/ac2
55Ut reference point XCAP server for supplementary servicesTS 24.623n/ac3
56Ut reference point XCAP client for supplementary servicesTS 24.623n/ac2
57Customized alerting tones application serverTS 24.182n/ac8
58Customized alerting tones UA clientTS 24.182n/ac2
59Customized ringing signal application serverTS 24.183n/ac8
60Customized ringing signal UA clientTS 24.183n/ac2
61SM-over-IP senderTS 24.341n/ac2
62SM-over-IP receiverTS 24.341n/ac2
63IP-SM-GWTS 24.341n/ac1
71IP-SM-GWTS 29.311n/ac10
81MSC Server enhanced for ICSTS 24.292n/ac12
81AMSC server enhanced for SRVCC using SIP interface TS 24.237n/ac12
81BMSC server enhanced for DRVCC using SIP interface TS 24.237n/ac12
82ICS user agentTS 24.292n/ac2
83SCC application serverTS 24.292n/ac9
84EATFTS 24.237n/ac12
85In-dialog overlap signalling application serverAnnex N.2, Annex N.3.3n/ac9
86In-dialog overlap signalling UA clientAnnex N.2, Annex N.3.3n/ac2
87Session continuity controller UETS 24.337n/ac2
88ATCF (proxy)TS 24.237n/ac13 (note 4)
89ATCF (UA)TS 24.237n/ac12 (note 4)
91Malicious communication identification application serverTS 24.616n/ac9
92USSI UETS 24.390n/ac2
92AUSSI UE supporting user-initiated USSD operationsTS 24.390n/ac17
92BUSSI UE supporting network-initiated USSD operationsTS 24.390n/ac17
93USSI ASTS 24.390n/ac3
93AUSSI AS supporting user-initiated USSD operationsTS 24.390n/ac18
93BUSSI AS supporting network-initiated USSD operationsTS 24.390n/ac18
94TP UETS 24.103n/ac14
95eP-CSCF (P-CSCF enhanced for WebRTC)TS 24.371n/ac15
101Business trunking in static mode of operation application serverTS 24.525n/ac16
102MCPTT clientTS 24.379n/ac19
103MCPTT serverTS 24.379n/ac20
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 TS 24.341. A.3A/71 is an AS providing the IP-SM-GW role to support the service level interworking for messaging as defined in TS 29.311.
NOTE 4:
An ATCF shall support both the ATCF (proxy) role and the ATCF (UA) role.
Item Value used in P-Access-Network-Info header field Reference RFC status Profile status
13GPP-GERAN[52] 4.4oc1
23GPP-UTRAN-FDD[52] 4.4oc1
33GPP-UTRAN-TDD[52] 4.4oc1
43GPP2-1X[52] 4.4oc1
53GPP2-1X-HRPD[52] 4.4oc1
63GPP2-UMB[52] 4.4oc1
73GPP-E-UTRAN-FDD[52] 4.4oc1
83GPP-E-UTRAN-TDD[52] 4.4oc1
8A3GPP-E-UTRAN-ProSe-UNRsubclause 7.2A.4 n/ac1
8B3GPP-NR-FDDsubclause 7.2A.4 n/ac1
8C3GPP-NR-TDDsubclause 7.2A.4 n/ac1
8D3GPP-NR-U-FDDsubclause 7.2A.4 n/ac1
8E3GPP-NR-U-TDDsubclause 7.2A.4 n/ac1
8W3GPP-NR-SATsubclause 7.2A.4 n/ac1
93GPP2-1X-Femto[52] 4.4oc1
11IEEE-802.11[52] 4.4oc1
12IEEE-802.11a[52] 4.4oc1
13IEEE-802.11b[52] 4.4oc1
14IEEE-802.11g[52] 4.4oc1
15IEEE-802.11n[52] 4.4oc1
16IEEE-802.11ac[52] 4.4oc1
21ADSL[52] 4.4oc1
22ADSL2[52] 4.4oc1
23ADSL2+[52] 4.4oc1
24RADSL[52] 4.4oc1
25SDSL[52] 4.4oc1
26HDSL[52] 4.4oc1
27HDSL2[52] 4.4oc1
28G.SHDSL[52] 4.4oc1
29VDSL[52] 4.4oc1
30IDSL[52] 4.4oc1
31xDSLsubclause 7.2A.4 oc1
41DOCSIS[52] 4.4oc1
51DVB-RCS2[52] 4.4oc1
523GPP-UTRAN[52] 4.4oc2
533GPP-E-UTRAN[52] 4.4oc2
543GPP-WLAN[52] 4.4oc2
553GPP-GAN[52] 4.4oc2
563GPP-HSPA[52] 4.4oc2
573GPP2[52] 4.4oc2
58untrusted-non-3GPP-VIRTUAL-EPCsubclause 7.2A.4 n/ac2
59VIRTUAL-no-PSsubclause 7.2A.4 n/ac2
60WLAN-no-PSsubclause 7.2A.4 n/ac2
613GPP-NRSubclause 7.2A.4 n/ac2
623GPP-NR-USubclause 7.2A.4 n/ac2
633GPP-NR-SATSubclause 7.2A.4 n/ac2
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.
It is mandatory to support at least one of these items.
Item Roles Reference RFC status Profile status
1UE performing the functions of an external attached network4.1
2UE performing the functions of an external attached network operating in static mode4.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.
Item Security mechanism Reference RFC status Profile status
1IMS AKA plus IPsec ESPclause 4.2B.1 n/ac1
2SIP digest plus check of IP associationclause 4.2B.1 n/ac2
3SIP digest plus Proxy Authenticationclause 4.2B.1 n/ac2
4SIP digest with TLSclause 4.2B.1 n/ac2
5NASS-IMS bundled authenticationclause 4.2B.1 n/ac2
6GPRS-IMS-Bundled authenticationclause 4.2B.1 n/ac2
7Trusted node authenticationclause 4.2B.1 n/ac3
8SIP over TLS with client certificate authenticationclause 4.2B.1 n/ac6
20End-to-end media security using SDESclause 4.2B.2 oc5
20AEnd-to-access-edge media security for MSRP using TLS and certificate fingerprintsclause 4.2B.2 n/ac4
20BEnd-to-access-edge media security for BFCP using TLS and certificate fingerprintsclause 4.2B.2 n/ac4
20CEnd-to-access-edge media security for UDPTL using DTLS and certificate fingerprintsclause 4.2B.2 n/ac4
21End-to-end media security using KMSclause 4.2B.2 oc5
22End-to-end media security for MSRP using TLS and KMSclause 4.2B.2 oc5
30End-to-access-edge media security using SDESclause 4.2B.2 n/ac4
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.
Up

Up   Top   ToC