SIPPING WG Rocky Wang Internet Draft Huawei Technologies Expires: July 28, 2006 January 25, 2006 A method to override the barring services draft-rocky-sipping-override-barring-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The document collects some approaches used to implement the functionalities of Override Barring Services in Session Initial Protocol (SIP), and gives detailed description of service flows for each type of the functionalities. Some methods such as SAML, CPC, which is used to implement service, are also dealt with in the document. Rocky Expires - July 2006 [Page 1] Internet-Draft override barring services January 2006 Table of Contents 1 Introduction.....................................................2 2 Conventions......................................................4 3 Possible proposals...............................................4 3.1 Type A barring service.........................................4 3.1.1 A solution based on SAML.....................................4 3.1.1.1 SIP-SIP service flow.......................................5 3.1.1.2 SIP-PSTN service flow......................................7 3.1.1.3 PSTN-SIP service flow......................................9 3.1.1.4 SIP bridge PSTN-PSTN service flow.........................11 3.1.2 A solution based on P-CPC...................................13 3.1.3 Summary of the above solutions..............................14 3.2 Type B barring service........................................15 3.2.1 In-band password collect....................................16 3.2.2 Out-band password collect...................................18 3.2.3 Challenge-based solution....................................21 4 Security Considerations.........................................23 5 IANA Considerations.............................................23 6 References......................................................23 6.1 Normative References..........................................23 6.2 Informational References......................................24 7 Acknowledgment..................................................24 8 Author's Address................................................25 9 Intellectual Property Statement.................................25 10 Disclaimer of Validity.........................................25 11 Copyright Statement............................................25 1 Introduction In PSTN network, there are a series of services, called barring services in general, that the subscriber can instruct the network to reject incoming calls if the preconditions are met. DND service is one of the most typical barring services. If the called party has subscribed DND service from his carrier and the service is activated, all the incoming normal calls will be rejected by the network directly. But there are some provisions for exceptional cases in which the calling party should have the opportunity to override the barring services to reach the called party even though the services are activated and the service-specific preconditions are met. For instance, police stations, emergency call centers and operators always hold higher priorities and have the rights to override the served subscriber's barring services, and calls from these types of subscribers should still be routed to the callee's terminal instead of being rejected. Rocky Expires - July 2006 [Page 2] Internet-Draft override barring services January 2006 In the current PSTN network, there are several classes of overriding barring services as described below which will be discussed in this document and deployed in the SIP network. For the convenience of description, DND is sometimes as a substitute of the barring services in the service flows we will discuss a little later in this document. Type A: The subscribers with some special features/characteristics will hold higher priorities and have the rights to override some other subscriber's barring services as the case mentioned above that the emergency center overrides common subscriber's DND. As some nation's services' rules, this type of overriding should be implemented as allocating a separate category value for each type of characterized user. And the category value will be conveyed through a well-defined parameter in ISUP, calling party category (CPC). In this case, if the called network server receives an incoming call request to a subscriber that his DND service is activated, the server will check whether the caller can override the callee's DND service. If yes, the request will be routed to the callee end-system. Otherwise, it will be rejected. The server will do the check based on the CPC parameter from the request message. Type B: The subscriber can set a key to override his barring service. When the subscriber's barring service is activated, the key will be taken into effect. Any one that makes a call by any line will be asked to input the key also. If the caller input a correct key as the subscriber set, the call request will be routed to the callee end-system, otherwise the request will be rejected directly. The subscriber can set his key anytime but not only when he active his barring services. Type C: More scenarios will be drafted later if there are. Security Assertion Markup Language (SAML) [I-D.saml-tech-overview- 1.1-03] is an XML extension for security information exchange that is being developed by SSTC of OASIS. SAML is a XML-based framework for creating and exchanging security information. SIP-SAML [I-D.draft-tschofenig-sip-saml-04] gives a method for using SAML in collaboration with SIP to accommodate richer authorization mechanisms and enable trait-based authorization where you are authenticated using roles or traits instead of identity. In particular, it provides a way for SIP to refer to SAML objects, and for recipients of SIP messages to use SAML in order to make more informed authorization decisions. Rocky Expires - July 2006 [Page 3] Internet-Draft override barring services January 2006 TISPAN is finding the solutions to simulate and emulate PSTN services in the IMS-based SIP network. The barring overriding feature is a common part of the services under research. Evidently, to complete the features of the ACR, DND and some other barring services, this is an essential part of them. This document has collected some known possible technical solutions for each type of barring service's overriding functionality. It can be used to provide the features in the SIP network to SIP subscribers, help readers find a reasonable way to simulate or emulate the traditional supplementary services. 2 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4]. 3 Possible proposals In this section, some service flows are drafted for each type of barring service. 3.1 Type A barring service For type A barring service, it is required to convey necessary information between network servers from the calling network to the called network. There are two totally different schemas are documented here, one is based on SAML and another is on an extension header. More possible schemas are welcome and will also be added into this document. 3.1.1 A solution based on SAML SAML is a XML-based framework for creating and exchanging security information. It can be used to fulfill this requirement to convey necessary information. In this section, we will document the service flows as different caller type and callee type. Rocky Expires - July 2006 [Page 4] Internet-Draft override barring services January 2006 3.1.1.1 SIP-SIP service flow Alice in Atlanta.com and Bob in Biloxi.com domain are SIP subscribers, that is, they will communicate with others by their SIP phone. Figure 1 shows the basic message flow of Alice overriding Bob’s barring service successfully. ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.atl | | Asserting | | proxy.bil | | Bob's | | phone | | anta.com | | Party | | oxi.com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | INVITE | | | | |------------>| | | | | 407 Proxy Auth. Req. | | | |<------------| | | | | ACK | | | | |------------>| | | | | INVITE | | | | |------------>| Request Assertion | | | |------------->| | | | | User Authentication | | | | and Authorization | | | |<-------------| | | | |------------->| | | | | SAML artifact| | | | |<-------------| | | | | INVITE + SAML artifact | | | |---------------------------->| | | | | SAML request | | | | |<-------------| | | | | SAML response + Assertion | | | |------------->| | | | | *(Note 1) | | | | | | | | | | INVITE | | |------------>| | 180 Ringing | |<--------------------------------------------------------| | | | 200 OK | |<--------------------------------------------------------| | ACK | |-------------------------------------------------------->| | Media Stream | |<=======================================================>| | | Figure 1: Type A overriding barring service flow (SIP-SIP) Rocky Expires - July 2006 [Page 5] Internet-Draft override barring services January 2006 Alice wants to make a call to Bob and when the call setup request reaches the proxy server of atlanta.com, the server will ask him or his phone for authentication by initiating a challenge procedure. After getting the challenge response and passing the verification, the proxy will contact the asserting party to request a SAML assertion or artifact. And then, the server will forward the call setup request to the proxy of biloxi.com with the addition of the received SAML assertion or artifact. After receiving the request message, the proxy server of biloxi.com will check the callee services. The server will reject the call if the barring service's precondition are met and no other services can be invoked as the information from the request and the callee subscriber's service subscription. But if the request takes a SAML assertion, the server SHOULD extract the information from the assertion which can help the caller override the callee's barring service. If the request takes a SAML artifact, the server needs to request the corresponding assertion from the asserting party. After getting the assertion, it will continue the process just like the request takes the SAML assertion. Suppose based on the information from the SAML assertion the caller can override the callee's barring service, the server will forward the call request to Bob's phone. Else, it will reject the request with a failure response. Any exception occurs, the proxy of biloxi.com will reject the call because of the barring service. For instance, the proxy server of biloxi.com does not have a trust SAML relationship with the asserting party which creates the SAML assertion or artifact received via the request message. Rocky Expires - July 2006 [Page 6] Internet-Draft override barring services January 2006 3.1.1.2 SIP-PSTN service flow Alice in Atlanta.com tries to make a call to a subscriber Bob in PSTN network. The caller's SIP network can interwork with the called PSTN network through a SIP/PSTN gateway. Figure 2 shows the basic message flow of Alice overriding Bob’s barring service successfully. ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.atl | | Asserting | | SIP/PSTN | | Bob's | | phone | | anta.com | | Party | | Gateway | | Switch | ----------- ------------- ------------- ------------- ----------- | | | | | | INVITE | | | | |------------>| | | | | 407 Proxy Auth. Req. | | | |<------------| | | | | ACK | | | | |------------>| | | | | | | | | | INVITE | | | | |------------>| Request Assertion | | | |------------->| | | | | User Authentication | | | | and Authorization | | | |<-------------| | | | |------------->| | | | |SAML assertion| | | | |<-------------| | | | | INVITE + SAML assertion | | | |---------------------------->| | | | | *(Note 1) | | | | | | | | | | IAM | | |------------>| | | *(Note 2) | | ACM | | 180 Ringing |<------------| |<------------------------------------------| | | | ANM | | 200 OK |<------------| |<------------------------------------------| | | ACK | | |------------------------------------------>| | | Media Stream |Media Stream | |<=========================================>|<===========>| | | | Figure 2: Type A overriding barring service flow (SIP-PSTN) Rocky Expires - July 2006 [Page 7] Internet-Draft override barring services January 2006 Alice wants to make a call to Bob and when the call setup request reaches the proxy server of atlanta.com, the server will ask him or his phone for authentication by initiating a challenge procedure. After get the challenge response and pass the verification, the proxy will contact the asserting party to request a SAML assertion or artifact. And then, the server will forward the call setup request to the SIP/PSTN interworking gateway with the addition of the received SAML assertion or artifact. After receives the request message, the gateway complete interworking between SIP and the protocol which is used in the PSTN network, e.g. ISUP here. No matter what the protocol is used in the PSTN network, but for the convenience of description and discussion, suppose it is ISUP. Before transfer the call establishing request to the callee's switch, the gateway will construct the outgoing request from the incoming request received based on the message, parameter and service flow interworking rules. After receives the request message, Bob's switch will check the callee services. The server will reject the call if the barring service's precondition are met and no other services can be invoked as the information from the request and the callee subscriber's service subscription. But if the request takes enough information to indicate that the caller can override the callee barring service, the callee switch will alert the callee subscriber. To get the information to override the callee barring service in Bob's switch, the gateway should collect it when it constructs the request message. If the incoming request message takes a SAML assertion, the gateway SHOULD extract the information from the assertion which will help the caller override the callee's barring service. If the request takes a SAML artifact, the server needs to request the corresponding assertion from the asserting party, and then extract the information from the assertion requested. But if the gateway does not have a trust SAML relationship with the asserting party, it SHOULD ignore the SAML assertion or artifact instead of using it. Rocky Expires - July 2006 [Page 8] Internet-Draft override barring services January 2006 3.1.1.3 PSTN-SIP service flow Alice in PSTN network tries to make a call to a subscriber Bob in SIP network of biloxi.com domain. Their networks can interwork through a PSTN/SIP gateway. Figure 3 shows the basic message flow of Alice overriding Bob’s barring service successfully. ----------- ------------- ------------- ----------- | Alice's | | PSTN/SIP | | proxy.bil | | Bob's | | Switch | | Gateway | | oxi.com | | phone | ----------- ------------- ------------- ----------- | | | | | IAM | | | |------------>| | | | *(Note 1) | | | | INVITE + SAML assertion | | | |---------------------------->| | | | *(Note 2) | | | | INVITE | | | |------------>| | | 180 Ringing | | ACM |<------------------------------------------| |<------------| | | | 200 OK | | ANM |<------------------------------------------| |<------------| ACK | | |------------------------------------------>| |Media Session| Media Session | |<===========>|<=========================================>| | | | Figure 3: Type A overriding barring service flow (PSTN-SIP) Alice wants to make a call to Bob and when the gateway received the call setup request, it can create an assertion based on signaling information from Alice and digitally sign it with his private key. The call is forwarded from the PSTN/SIP gateway to the proxy of Bob's domain. And the INVITE request will takes a SAML assertion or artifact. After receiving the request message, the proxy server of biloxi.com will check the callee services. The server will reject the call if the barring service's precondition are met and no other services can be invoked as the information from the request and the callee subscriber's service subscription. But if the request takes a SAML assertion, the server SHOULD extract the information from the assertion which can help the caller override Rocky Expires - July 2006 [Page 9] Internet-Draft override barring services January 2006 the callee's barring service. If the request takes a SAML artifact, the server needs to request the corresponding assertion from the gateway and then extract the information from the assertion requested. But if the proxy does not have a trust SAML relationship with the gateway, it SHOULD ignore the SAML assertion or artifact instead of using it. Suppose based on the information from the SAML assertion the caller can override the callee's barring service, the server will forward the call request to Bob's phone. Else, it will reject the request with a failure response. Any exception occurs, the proxy of biloxi.com will reject the call because of the barring service. Rocky Expires - July 2006 [Page 10] Internet-Draft override barring services January 2006 3.1.1.4 SIP bridge PSTN-PSTN service flow Alice tries to make a call to a subscriber Bob. Both of them are in PSTN network and SIP bridges their networks to provide the interworking functions. Figure 4 shows the basic message flow of Alice overriding Bob's barring service successfully. ------------- ------------- ----------- | PSTN/SIP | | SIP/PSTN | ----------- | PSTN | | Gateway | | Gateway | | Bob's | | Switch | | (O-IWU) | | (O-IWU) | | phone | ----------- ------------- ------------- ----------- | | | | | IAM | | | |------------>| | | | *(Note 1) | | | | INVITE + SAML assertion | | | |---------------------------->| | | | *(Note 2) | | | | IAM | | | |------------>| | | | | | | | ACM | | | 180 Ringing |<------------| | ACM |<----------------------------| | |<------------| | ANM | | | 200 OK |<------------| | ANM |<----------------------------| | |<------------| ACK | | | |---------------------------->| | |Media Stream | Media Stream |Media Stream | |<===========>|<===========================>|<===========>| | | | | Figure 4: Type A overriding barring service flow (PSTN-PSTN) Alice wants to make a call to Bob and his switch will initiates a call setup request to a PSTN/SIP gateway called PSTN-to-SIP gateway or O-IWU. O-IWU will forward the request into SIP network. And eventually, the request will enter PSTN network through a SIP/PSTN gateway called I-IWU or SIP-to-PSTN gateway and I-IWU will forward the call to Bob's home switch. When O-IWU gets the request, it can create an assertion based on signaling information from Alice and digitally sign it with his private key. The call is forwarded from the PSTN/SIP gateway to the SIP network. And the INVITE request will takes a SAML assertion or artifact. Rocky Expires - July 2006 [Page 11] Internet-Draft override barring services January 2006 After receives the request message, the I-IWU complete interworking between SIP and the protocol which is used in the PSTN network. Before transfer the request to the callee's switch, the I-IWU will construct the outgoing request from the incoming request received based on the message, parameter and service flow interworking rules. After receives the request message, Bob's switch will check the callee services. The server will reject the call if the barring service's precondition are met and no other services can be invoked as the information from the request and the callee subscriber's service subscription. But if the request takes enough information to indicate that the caller can override the callee barring service, the callee switch will alert the callee subscriber. To get the information to override the callee barring service in Bob's switch, the I-IWU should collect it when it constructs the request message. If the incoming request message takes a SAML assertion, the I-IWU should extract the information from the assertion which will help the caller override the callee's barring service. If the request takes a SAML artifact, the server needs to request the corresponding assertion from the O-IWU, and then extract the information from the assertion requested. But if the I-IWU does not have a trust SAML relationship with the O-IWU, it SHOULD ignore the SAML assertion or artifact instead of using it. Rocky Expires - July 2006 [Page 12] Internet-Draft override barring services January 2006 3.1.2 A solution based on P-CPC SS7 ISUP [13] defines a Calling Party's Category (CPC) parameter that characterizes the originating subscriber used to originate a call and carries other important information that can describe the originating party. Based on the CPC parameter from the calling network, the called network can do some predefined special processes related to it. Some national PSTN supplementary service standards have defined the functionality of overriding barring services in use of the CPC. A simple way to simulate it in SIP is to make an approach to convey the similar information by the SIP messages in the similar case, just like conveying CPC information by the call setup request message, INVITE. [12] has defined an extension header, P-CPC to convey the calling party category derived from the ISUP protocol including its meaning and the defined possible values. In a certain network, for instance the IMS network, the subscribers accessing the network are controllable. When a subscriber initiates a request, the network can check all the parameters and only send trusted information to the next node. In this case, the called network can use any information extracted from the request, including P-CPC and based on it, the called network can make a decision on whether the caller can override the callee's barring service and if yes, the called network can transfer the request to the called party end-system. In IMS network, when a subscriber initiates a call setup request, a so-called P-CSCF proxy will route the call to a so-called S-CSCF proxy which keeps the subscriber's information, its registration and it can get the subscriber's subscription locally or from a standalone server using a defined standardized interface. Before the S-CSCF route the call request out, it can check and modify the header if it is already present, or create a new one if not. Any way, the request from the S-CSCF will take a P-CPC header and its value is a correct calling party category. After it reaches the called network, the called network server, S- CSCF or a standalone application server will check whether the caller has rights to override the called party's barring service using the CPC value from the P-CPC header if the CPC value is present. Rocky Expires - July 2006 [Page 13] Internet-Draft override barring services January 2006 3.1.3 Summary of the above solutions Based on a third-party asserting party, the called network can use SAML to get some trusted calling party information from the received message. And based on all the information from the asserting party and the received information, it can provide more functionalities and services including overriding barring services. Fundamentally, there must be a third-party asserting party, and both of the calling and called network server must have a trusted SAML relationship with it. Note that the asserting party is a logical entity and can physically coexist with any network server, for example, the proxy server of the calling or called network, the PSNT-SIP gateway, or the third network server. If the P-CPC extension header is used, it is assumed that the header is created in a trusted way. For example, in a certain network the behavior of each network element and all the subscribers accessing the network are fully controlled by the carrier. Before forwarding a call setup request to a next element, the calling network will create or overwrite a P-CPC header and fill a correct value of the calling subscriber in the header. And then the called network server will be able to use it to give different functionalities to different types of subscribers. If the called network server is not sure the value is trusted, it should not do anything related to the value. Rocky Expires - July 2006 [Page 14] Internet-Draft override barring services January 2006 3.2 Type B barring service For type B barring service, it will give the caller an opportunity to override the barring service by a key. The key can be set or modified in several ways. For instance, the subscriber can set it by self- service web page, by sending a specified message to the service center, etc. There are 3 means to implement the overriding barring functionality and they are documented here. More possible schemas are welcome and will be added into this document also. Rocky Expires - July 2006 [Page 15] Internet-Draft override barring services January 2006 3.2.1 In-band password collect The called service server will establish a session with the caller to play announcement to him and collect digits from him. When the input digits are the same as the key, then the server will forward the call to the called party end-system. Figure 6 gives a successful service flow. ----------- ------------- ------------- ----------- | Alice's | | proxy.atl | | server.bi | | Bob's | | phone | | anta.com | | loxi.com | | phone | ----------- ------------- ------------- ----------- | | | | | INVITE | | | |------------>| INVITE | | | |---------------------------->| | | | | | | 183 Progress | | |<------------------------------------------| | | PRACK | | |------------------------------------------>| | | 200 OK (PRACK) | | |<------------------------------------------| | | Media Stream | | |<=========================================>| | | *(Note 1) | | | INVITE | | |------------>| | | 180 Ringing | | |<------------| | *(Note 2) | | 180 Ringing | | |<------------------------------------------| | | PRACK | | |------------------------------------------>| | | 200 OK (PRACK) | | |<------------------------------------------| | | | 200 OK | | 200 OK (INVITE) |<------------| |<------------------------------------------| | | ACK | | |------------------------------------------>| ACK | | |------------>| | Media Stream | |<=======================================================>| | | Figure 6: Type B In-band password collect service flow Rocky Expires - July 2006 [Page 16] Internet-Draft override barring services January 2006 When the called party service server, server.biloxi.com, receives the request and the type B barring service is triggered, it will establish a session with the caller and play announcement to him to ask for the key. The caller will hang-on to finish the request. He can also try to continue it by pressing the digits of the key. The digits will be transferred to the server by the in-band signals or DTMF package which is defined by RFC2833. If the key doesn't match, the server will reject the request with a failure response. If it matches, the server will forward the request to Bob's phone and the call will be established after Bob hang up. If the server runs as a proxy, it needs to release the dialog between itself and the caller, and finally another dialog will be established between Bob's phone and Alice's phone. And the server can also implement it as a 3pcc controller. In this mode, another dialog will be established between the server and Bob's phone. Rocky Expires - July 2006 [Page 17] Internet-Draft override barring services January 2006 3.2.2 Out-band password collect The called service server will establish a session with the caller to play announcement to him, and establish a subscription with the caller to collect digits from him by sending a SUBSCRIBE with KPML request body. When the input digits are the same as the key, then the server will forward the call to the called party end-system. Figure 6 gives a successful service flow. Rocky Expires - July 2006 [Page 18] Internet-Draft override barring services January 2006 ----------- ------------- ------------- ----------- | Alice's | | proxy.atl | | server.bi | | Bob's | | phone | | anta.com | | loxi.com | | phone | ----------- ------------- ------------- ----------- | INVITE | | | |------------>| INVITE | | | |---------------------------->| | | 183 Progress | | |<------------------------------------------| | | PRACK | | |------------------------------------------>| | | 200 OK (PRACK) | | |<------------------------------------------| | | Media Stream | | |<==========================================| | | *(Note 1) | | SUBSCRIBE | | |<------------------------------------------| | | 202 Accepted (SUBSCRIBE) | | |------------------------------------------>| | | NOTIFY | | |------------------------------------------>| | | 200 OK (NOTIFY) | | |<------------------------------------------| | | | | | NOTIFY (key pressed) | | |------------------------------------------>| | | 200 OK (NOTIFY) | | |<------------------------------------------| | | *(Note 2) | INVITE | | |------------>| | | 180 Ringing | | *(Note 3) |<------------| | 180 Ringing | | |<------------------------------------------| | | PRACK | | |------------------------------------------>| | | 200 OK (PRACK) | | |<------------------------------------------| | | | 200 OK | | 200 OK (INVITE) |<------------| |<------------------------------------------| | | ACK | | |------------------------------------------>| ACK | | |------------>| | Media Stream | |<=======================================================>| | | Figure 6: Type B KPML password collect service flow Rocky Expires - July 2006 [Page 19] Internet-Draft override barring services January 2006 When the called party service server, server.biloxi.com, received the request and the type B barring service is triggered, it will establish a session with the caller to play announcement to him to ask for the key. And at the same time, it will send a SUBSCRIBE request to the caller to establish a subscription to collect the digits. The SUBSCRIBE request will include a KPML request body. The caller will hang-on to finish the request. He can also try to continue it by pressing the digits of the key. The digits will be transferred to the server in NOTIFY messages as defined in [KPML] specification. If the key doesn't match, the server will reject the request with a failure response. If it matches, the server will forward the request to Bob's phone and the call will be established after Bob hang up. If the server runs as a proxy, it needs to release the dialog between itself and the caller, and finally another dialog will be established between Bob's phone and Alice's phone. And the server can also implement it as a 3pcc controller. In this mode, another dialog will be established between the server and Bob's phone. Rocky Expires - July 2006 [Page 20] Internet-Draft override barring services January 2006 3.2.3 Challenge-based solution Based on the challenge technology, it is possible that the called party service server, server.biloxi.com, get the key from the response to the challenge request. ----------- ------------- ------------- ----------- | Alice's | | proxy.atl | | server.bi | | Bob's | | phone | | anta.com | | loxi.com | | phone | ----------- ------------- ------------- ----------- | | | | | INVITE | | | |------------>| INVITE | | | |---------------------------->| | | | | | | 407 Password Required | | |<------------------------------------------| | | ACK | | |------------------------------------------>| | | *(Note 1) | | INVITE | | |------------------------------------------>| | | *(Note 2) | | | INVITE | | |------------>| | | 180 Ringing | | 180 Ringing |<------------| |<------------------------------------------| | | PRACK | | |------------------------------------------>| | | 200 OK (PRACK) | | |<------------------------------------------| | | | 200 OK | | 200 OK (INVITE) |<------------| |<------------------------------------------| | | ACK | | |------------------------------------------>| ACK | | |------------>| | Media Stream | |<=======================================================>| | | Figure 7: Type B Challenge-based password collect service flow When the called party service server, server.biloxi.com, receives the request, and the type B barring service is triggered, it will return a failure response (e.g. 407 Password Required) with challenge request to the caller. Rocky Expires - July 2006 [Page 21] Internet-Draft override barring services January 2006 After receiving the response, the caller phone will request the caller to provide a key to complete the service. The caller will hang-on to finish the request. He can also try to continue it by inputting the digits of the key. And then, his phone will get a second try with a challenge response. After getting the new request, the server will check the response in using the password to override Bob's barring service, some information it created and some other information get from the request. If the key doesn’t match, the server will simply reject the request with a failure response. If it matches, the server will forward the request to Bob's phone and the call will be established after Bob hang up. Just as followed, the server can be any logical entity defined by RFC3261. Rocky Expires - July 2006 [Page 22] Internet-Draft override barring services January 2006 4 Security Considerations This draft has collected several possible solutions to override the barring services. Several technologies are reused here, SAML, an extension header P-CPC, in-band DTMF collect, out-band key collect and challenge procedure and their security problems have been considered in the related document separately. The combination of them will not bring any new security problems. 5 IANA Considerations This document requires no IANA actions. 6 References 6.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J., Schulzrinne, H., "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [6] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo., "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). ", RFC 3725, April 2004. [7] H. Tschofenig, J. Peterson, J. Polk, D. Sicker, M. Tegnander, "Using SAML for SIP", draft-tschofenig-sip-saml-04.txt, July 18, 2005. [8] International Telecommunications Union, "Recommendation Q.763: Signalling System No. 7: ISDN user part formats and codes", December 1999, . Rocky Expires - July 2006 [Page 23] Internet-Draft override barring services January 2006 [9] Hodges, J., "application/saml+xml Media Type Registration", draft-hodges-saml-mediatype-01 (work in progress), June 2004. [10] Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", draft-ietf-sipping-trait- authz-01 (work in progress), February 2005. [11] R. Jesske, D. Alexeitsev, M. Garcia-Martin, "Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute", draft-jesske- sipping-tispan-requirements-02, October 6, 2005 [12] Rocky Wang, Youzhu Shi, "A header to deliver the calling party category", draft-rocky-sipping-calling-party-category-01.txt, October 21, 2005. [13] American National Standards Institute, "ANSI T1.113-2000, Signaling System No. 7, ISDN User Part", 2000, . 6.2 Informational References [14] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [15] ETSI, "Services and Protocols for Advanced Networks (SPAN); Anonymous Call Rejection (ACR) Supplementary Service; Service description", ETSI EN 301 798 v1.1.1, October 2000, . [16] Rohan Mahy, "The Calling Party's Category tel URI Parameter", draft-mahy-iptel-cpc-02 (work in progress), February 21, 2005. 7 Acknowledgment I would like to thank Jonathan Rosenberg for giving us the idea to implement the functionalities to override barring services, and Dean Wills and Rohan Mahy for giving me the chance to collect the approaches of the functionality. I also express my gratitude to Paul Kyzivat, James M. Polk, Jeroen Van Bemmel, Garcin Sebastien, Michael Hammer, Anders Kristensen, Peili Xu, and Xiaowen Li for their detailed comments on the services and the P-CPC draft. Rocky Expires - July 2006 [Page 24] Internet-Draft override barring services January 2006 8 Author's Address Rocky Wang Huawei Technologies Co., Ltd. Huadian Building, Huawei Industrial Base, Bantian, Longgang District, Shenzhen 518129, P.R.China EMail: rocky.wang@huawei.com 9 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 10 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Rocky Expires - July 2006 [Page 25]