A.2 Service configuration
24.6113GPPAnonymous Communication Rejection (ACR) and Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS
Figure A.2.1: Service configuration example
1. HTTP GET request (UE to AP) – see example in table A.2-1
The UE wants to retrieve the supported conditions for communication barring from the AS.
Table A.2-1: HTTP GET request (UE to AP)
GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-barring-serv-cap HTTP/1.1
Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org
Date: Thu, 16 Jun 2011 10:50:33 GMT
X-3GPP-Intended-Identity: "sip:user1@home1.net"
2. HTTP 401 (Unathorized) response (AP to UE) – see example in table A.2-2
Upon receiving an unauthorized HTTP GET request the AP authenticates the UE.
Table A.2-2: HTTP 401 (Unathorized) request (AP to UE)
HTTP/1.1 401 Unauthorized
Date: Thu, 16 Jun 2011 10:50:34 GMT
WWW-Authenticate: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="47364c23432d2e131a5fb210812c", qop=auth-int
Content-Length: 0
3. HTTP GET request (UE to AP) – see example in table A.2-3
The UE repeats the HTTP GET request including the Authorization header.
Table A.2-3: HTTP GET request (UE to AP)
GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-barring-serv-cap HTTP/1.1
Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org
Date: Thu, 16 Jun 2011 10:50:36 GMT
Authorization: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="47364c23432d2e131a5fb210812c", username="sip:user1@home1.net", qop=auth-int,
uri="/simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-barring-serv-cap", response="2c8ee200cec7f6e966c932a9242554e4", cnonce="dcd99agsfgfsa8b7102dd2f0e8b1", nc=00000001
X-3GPP-Intended-Identity: "sip:user1@home1.net"
4. HTTP GET request (AP to AS) – see example in table A.2-4
The AP forwards the HTTP GET request to the AS.
Table A.2-4: HTTP GET request (AP to AS)
GET /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/communication-barring-serv-cap HTTP/1.1
Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org
Via: HTTP/1.1 ap.home1.net
Date: Thu, 16 Jun 2011 10:50:38 GMT
X-3GPP-Asserted-Identity: "sip:user1@home1.net"
5. HTTP 200 (OK) response (AS to AP) – see example in table A.2-5
The AS returns the supported conditions for communication barring. The <serv-cap-media> child element of the <serv-cap-conditions> element describes that audio and video media are allowed to be used as Communication Barring rule conditions. The other child elements of the <serv-cap-conditions> element list the conditions that are not provisioned for the user. If a service capability for a condition is not listed from the list of conditions specified in clause 4.9.1.4 then the condition is provisioned for the user. The following conditions are provisioned: roaming, international, international-exHC.
Table A.2-5: HTTP 200 (OK) response (AS to AP)
HTTP/1.1 200 OK
Date: Thu, 16 Jun 2011 10:50:40 GMT
Etag: "eti87"
Content-Type: application/xcap-el+xml; charset="utf-8"
Content-Length: (…)
<communication-barring-serv-cap active="true">
<serv-cap-conditions>
<serv-cap-anonymous provisioned="false"></serv-cap-anonymous>
<serv-cap-communication-diverted provisioned="false"></serv-cap-communication-diverted>
<serv-cap-external-list provisioned="false"></serv-cap-external-list>
<serv-cap-identity provisioned="false"></serv-cap-identity>
<serv-cap-media>
<media>audio</media>
<media>video</media>
</serv-cap-media>
<serv-cap-other-identity provisioned="false"></serv-cap-other-identity>
<serv-cap-presence-status provisioned="false"></serv-cap-presence-status>
<serv-cap-rule-deactivated provisioned="false"></serv-cap-rule-deactivated>
<serv-cap-validity provisioned="false"></serv-cap-validity>
</serv-cap-conditions>
</communication-barring-serv-cap>
6. HTTP 200 (OK) response (AP to UE) – see example in table A.2-6
The AP routes the HTTP 200 (OK) response to the UE.
Table A.2-6: HTTP 200 (OK) response (AP to UE)
HTTP/1.1 200 OK
Via: HTTP/1.1 ap.home1.net
Date: Thu, 16 Jun 2011 10:50:42 GMT
Authentication-Info: nextnonce="e966c32a924255e42c8ee20ce7f6"
Etag: "eti87"
Content-Type: application/simservs+xml; charset="utf-8"
Content-Length: (…)
(…)
7. HTTP PUT request (UE to AP) – see example in table A.2-7
The UE creates a new rule to activate the ICB service without conditions. If a rule with id="rule1" previously existed then the new rule replaces that rule. The rule has an empty <conditions> element.
Table A.2-7: HTTP PUT request (UE to AP)
PUT /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/incoming-communication-barring/ruleset/rule%5b@id=%22rule1%22%5d HTTP/1.1
Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org
Date: Thu, 16 Jun 2011 10:52:33 GMT
Authorization: Digest realm="xcap.mnc012.mcc345.ipxuni.3gppnetwork.org", nonce="e966c32a924255e42c8ee20ce7f6", username="sip:user1@home1.net", qop=auth-int,
uri="/simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/incoming-communication-barring/ruleset", response="adq3283hww88whhjw98822333ddd32", cnonce="wqesatt874873j3gg3kk39944hhhee", nc=00000001
X-3GPP-Intended-Identity: sip:user1@home1.net
Content-Type: application/xcap-el+xml; charset="utf-8"
Content-Length: (…)
<cp:rule id="rule1">
<cp:conditions>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
8. HTTP PUT request (AP to AS) – see example in table A.2-8
The AP forwards the HTTP PUT request to the AS.
Table A.2-8: HTTP PUT request (AP to AS)
PUT /simservs.ngn.etsi.org/users/sip:user1@home1.net/simservs.xml/~~/simservs/incoming-communication-barring/ruleset/rule%5b@id=%22rule1%22%5d HTTP/1.1
Host: xcap.mnc012.mcc345.ipxuni.3gppnetwork.org
Via: HTTP/1.1 ap.home1.net
Date: Thu, 16 Jun 2011 10:52:35 GMT
X-3GPP-Asserted-Identity: sip:user1@home1.net
Content-Type: application/xcap-el+xml; charset="utf-8"
Content-Length: (…)
(…)
9. HTTP 200 (OK) response (AS to AP) – see example in table A.2-9
The AS acknowledges the addition of the new ICB rule with a HTTP 200 (OK) response.
Table A.2-9: HTTP 200 (OK) response (AS to AP)
HTTP/1.1 200 OK
Date: Thu, 16 Jun 2011 10:52:37 GMT
Etag: "efefefef"
Content-Length: 0
10. HTTP 200 (OK) response (AP to UE) – see example in table A.2-10
The AP routes the HTTP 200 (OK) response to the UE.
Table A.2-10: HTTP 200 (OK) response (AS to AP)
HTTP/1.1 200 OK
Via: HTTP/1.1 ap.home1.net
Date: Thu, 16 Jun 2011 10:52:38 GMT
Authentication-Info: nextnonce="737jkjssj733hjjk3hjk3999ss3kj"
Etag: "efefefef"
Content-Length: 0
Annex B (informative):
Example of filter criteria
This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria evaluation.
When the initial request matches the conditions of the next unexecuted IFC rule for the served user which points to the ACR service and the P-Asserted-Identity header is set to "id", "header" or "user" or "critical", the communication is forwarded to the AS.
An example of an Initial Filter Criteria (IFC) Trigger Point configurations under the assumption that the ACR service is a standalone service that can be invoked by a very specific triggerpoint active at the destination S-CSCF:
– (Method="INVITE" AND [Header="P-Asserted-Identity"] AND [Header="Privacy", Content="id"]); or
– (Method="INVITE" AND [Header="P-Asserted-Identity"] AND [Header="Privacy", Content="header"]); or
– (Method="INVITE" AND [Header="P-Asserted-Identity"] AND [Header="Privacy", Content="user"]); or
– (Method="INVITE" AND [Header="P-Asserted-Identity"] AND [Header="Privacy", Content="critical"]).
NOTE 1: The coding of the Initial Filter Criteria is described in 3GPP TS 29.228 [12].
NOTE 2: In this case there is a one to one relationship with the conditions that express the rejection cases for the ACR service as specified in clause 4.5.2.6.1 "Action for ACR at the terminating AS".
NOTE 3: In practice it is more likely that all INVITE requests are forwarded to the AS, because there is more services to execute then ACR alone. This is already apparent when the combined service ACR/ICB is deployed.
If the AS cannot suppress ICB for for a call identified as a PSAP callback, an IFC bypassing the ICB AS can be used. An example IFC using the PSAP callback indicator specified in IETF RFC 7090 [21] is:
– Method: "INVITE" and not Priority header field with a "psap-callback" header field value.
Annex C (informative):
Change history
|
TISPAN # |
TISPAN Doc. |
CR |
Subject/Comment |
|---|---|---|---|
|
11 |
11TD157 |
001 |
"ICB identity rules should be matched against the Referred-By header" |
|
11 |
11TD157 |
002 |
"To avoid the effects between OIP and ACR service" |
|
12 |
12TD062 |
003 |
Correct User Configuration XML Schema errors |
|
12 |
12TD062 |
004 |
Change simservs XCAP namespace |
|
12 |
12TD062 |
005 |
Corrections to ACR call flow |
|
12 |
12TD062 |
006 |
wrong reference |
|
13 |
SS-060040 |
007r1 |
ETSI TS 183 011 (CB) – Incorporation of 3GPP requirements |
|
13 |
12bTD326r2 |
008 |
Communication Barring on roaming |
|
13 |
12tTD104r1 |
009 |
Rule conditions correction |
|
14bis |
14bTD413r4 |
010 |
CR to TS 183 011 |
|
14ter |
14tTD416r1 |
011 |
Correction of XML |
|
15bis |
15bTD336r3 |
012 |
Correction of XML Schema and misalignment |
|
15bis |
15bTD441r1 |
013 |
Correction of the use of the terms Interaction and Interworking in the ACR-CB Simulation Service description |
|
15bis |
15b350 |
014 |
Add interaction between ACR&CB and CONF (Corresponding CR 15bTD352) |
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2006-03 |
Publication as ETSI TS 183 011 |
1.1.1 |
|||||
|
2007-03 |
Publication as ETSI TS 183 011 |
1.2.1 |
|||||
|
2008-01 |
Publication as ETSI TS 183 011 |
1.3.0 |
|||||
|
2008-01 |
Convertsion to 3GPP TS 24.411 |
1.3.1 |
|||||
|
2008-01 |
Technically identical copy as 3GPP TS 24.611 as basis for further development. |
1.3.2 |
|||||
|
2008-02 |
Implemented C1-080102 |
1.4.0 |
|||||
|
2008-04 |
Implemented C1-081237, C1-080875, C1-080888, C1-080889, C1-081092, C1-081093, C1-081182 |
1.5.0 |
|||||
|
2008-05 |
Implemented C1-81832, C1-81914 Editorial: Cover page change to Release 8, correction of Key words Incorporation of comments from ETSI Edit help |
1.6.0 |
|||||
|
2008-05 |
Editorial changes done by MCC |
1.6.0 |
1.6.1 |
||||
|
2008-06 |
CT#40 |
CP-080331 |
CP-080331 was approved by CP-080331 and version 8.0.0 is created by MCC for publishing |
1.6.1 |
8.0.0 |
||
|
2008-06 |
Verson 8.0.1 created to include attachments (.xml and .xsd files) |
8.0.0 |
8.0.1 |
||||
|
2008-09 |
CT#41 |
CP-080539 |
0001 |
1 |
Allow SIP based user configuration mechanism for configuring supplementary services |
8.0.1 |
8.1.0 |
|
2008-09 |
CT#41 |
CP-080533 |
0002 |
Applicability statement in scope |
8.0.1 |
8.1.0 |
|
|
2008-09 |
CT#41 |
CP-080533 |
0003 |
Identification of AS procedures |
8.0.1 |
8.1.0 |
|
|
2008-12 |
CT#42 |
CP-080865 |
0004 |
1 |
Clarification of B2BUA and proxy roles for AS |
8.1.0 |
8.2.0 |
|
2008-12 |
CT#42 |
CP-080864 |
0005 |
2 |
Interaction between SIP and Ut based service configuration |
8.1.0 |
8.2.0 |
|
2008-12 |
CT#42 |
Editorial cleanup by MCC |
8.1.0 |
8.2.0 |
|||
|
2009-06 |
CT#44 |
CP-090432 |
0009 |
2 |
Service capability indication for CB |
8.2.0 |
9.0.0 |
|
2009-06 |
CT#44 |
CP-090432 |
0010 |
2 |
Addition of international-communications to barring conditions |
8.2.0 |
9.0.0 |
|
2009-09 |
CT#45 |
CP-090687 |
0012 |
Media capabilities for Call Barring |
9.0.0 |
9.1.0 |
|
|
2009-09 |
CT#45 |
CP-090682 |
0014 |
4 |
Dynamic barring of users for ICB |
9.0.0 |
9.1.0 |
|
2009-09 |
CT#45 |
CP-090687 |
0016 |
1 |
Example doc for CB |
9.0.0 |
9.1.0 |
|
2009-12 |
CT#46 |
CP-090928 |
0017 |
2 |
CB serv-cap corrections |
9.1.0 |
9.2.0 |
|
2009-12 |
CT#46 |
CP-090928 |
0018 |
1 |
Corrections to EXAMPLE |
9.1.0 |
9.2.0 |
|
2010-03 |
CT#47 |
CP-100141 |
0019 |
Cleanup EN |
9.2.0 |
9.3.0 |
|
|
2011-03 |
CT#51 |
Upgrade to Rel-10 |
9.3.0 |
10.0.0 |
|||
|
2011-09 |
CT#53 |
CP-110657 |
0021 |
2 |
<conditions> element values |
10.0.0 |
10.1.0 |
|
2011-09 |
CT#53 |
CP-110695 |
0022 |
1 |
Service configuration signalling flow |
10.1.0 |
11.0.0 |
|
2011-12 |
CT#54 |
CP-110857 |
0027 |
2 |
Use of "Critical" |
11.0.0 |
11.1.0 |
|
2012-09 |
CT#57 |
CP-120583 |
0031 |
Incorrect reference to OMA Common Policy Schema |
11.1.0 |
11.2.0 |
|
|
2013-06 |
CT#60 |
CP-130415 |
0032 |
5 |
PSAP callback ICB suppression |
11.2.0 |
12.0.0 |
|
2013-06 |
CT#60 |
CP-130265 |
0033 |
3 |
Barring of incoming OPTIONS requests |
11.2.0 |
12.0.0 |
|
2013-09 |
CT#61 |
CP-130507 |
0035 |
draft-ietf-ecrit-psap-callback reference update |
12.0.0 |
12.1.0 |
|
|
2013-12 |
CT#62 |
CP-130758 |
0036 |
2 |
Reference update: draft-ietf-ecrit-psap-callback |
12.1.0 |
12.2.0 |
|
2014-03 |
CT#63 |
CP-140143 |
0037 |
1 |
Correction of history related header field name |
12.2.0 |
12.3.0 |
|
2014-12 |
CT#66 |
CP-140833 |
0040 |
1 |
Reference update: RFC 7090 (draft-ietf-ecrit-psap-callback) |
12.3.0 |
12.4.0 |
|
2014-12 |
CT#66 |
CP-140826 |
0042 |
Reference Update: RFC7315 |
12.3.0 |
12.4.0 |
|
|
2014-12 |
CT#66 |
CP-140837 |
0043 |
1 |
simservs filename correction |
12.3.0 |
12.4.0 |
|
2015-06 |
CT#68 |
CP-150328 |
0046 |
2 |
White lists and barring |
12.4.0 |
13.0.0 |
|
2015-12 |
CT#70 |
CP-150709 |
0047 |
1 |
Service capability unconditional for barring |
13.0.0 |
13.1.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
CT#75 |
CP-170131 |
0048 |
6 |
B |
Password handling for communication barring |
14.0.0 |
|
2017-03 |
CT#75 |
CP-170131 |
0049 |
4 |
B |
Password option for barring service |
14.0.0 |
|
2017-12 |
CT#78 |
CP-173071 |
0051 |
2 |
B |
Anonymous Communication Rejection (ACR) and Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem |
15.0.0 |
|
2018-12 |
CT#82 |
CP-183067 |
0053 |
1 |
A |
Correction of the XML Scheme |
15.1.0 |
|
2019-12 |
CT#86 |
CP-193111 |
0054 |
1 |
B |
Adding interactions with "Multi-Device" and "Multi-Identity" services |
16.0.0 |
|
2021-06 |
CT#92e |
CP-211156 |
0055 |
1 |
D |
Inclusive language review of TS 24.611 |
17.0.0 |