Internet DRAFT - draft-rocky-sipping-override-barring
draft-rocky-sipping-override-barring
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, <http://www.itu.int>.
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,
<http://www.ansi.org>.
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, <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=6618>.
[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]
