the resource, and the other containing information that lead to the
firing of the detection point.
5.3.12. State agents
State agents are not used in SPIRITS.
5.3.13. Examples
This section contains example call flows for a SPIRITS service called
Internet Caller-ID Delivery (ICID). One of the benchmark SPIRITS
service, as described in section 2.2 of [1] is Internet Caller-ID
delivery:
This service allows the subscriber to see the caller’s number or
name or both while being connected to the Internet. If the
subscriber has only one telephone line and is using the very line
for the Internet connection, the service is a subset of the ICW
service and follows the relevant description in Section 2.1.
Otherwise, the subscriber’s IP host serves as an auxiliary device
of the telephone to which the call is first sent.
We present an example of a SPIRITS call flow to realize this service.
Note that this is an example only, not a normative description of the
Internet Caller-ID service.
Further text and details of SIP messages below refer to the call flow
provided in Figure 3. Figure 3 depicts the 4 entities that are an
integral part of any SPIRITS service (the headings of the entities
refer to the names established in Figure 1 in [1]) -- the SPIRITS
subscriber, the SPIRITS notifier and the SCF. Note that the SPIRITS
gateway is not included in this figure; logically, SPIRITS messages
flow between the SPIRITS server and the SPIRITS client. A gateway,
if present, may act as a proxy.
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Arm DP |
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 3: Sample call flow
This call flow depicts an overall operation of a "subscriber"
successfully subscribing to the IN Termination_Attempt_Authorized DP
(the "subscriber" is assumed to be a user, possibly at work, who is
interested in knowing when he/she gets a phone call to his/her home
phone number) -- this interaction is captured in messages F1 through
F8 in Figure 3. The user sends (F1) a SIP SUBSCRIBE request
identifying the DP it is interested in along with zero or more
parameters relevant to that DP (in this example, the
Termination_Attempt_DP will be employed). The SPIRITS notifier in
turns interacts with the SCF to arm the Termination_Attempt_DP for
the service (F2). An immediate NOTIFY with the current state
information is send to the subscriber (F4, F5).
At some point after the above sequence of events has transpired, the
PSTN gets a call to the users phone. The SSF informs the SCF of this
event when it encounters an armed Termination_Attempt_DP (not shown
in Figure 3). The SCF informs the SPIRITS notifier of this event
(F6).
When the SPIRITS notifier receives this event, it forms a SIP NOTIFY
request and directs it to the SPIRITS subscriber (F7). This NOTIFY
will contain all the information elements necessary to identify the
caller to the subscriber. The subscriber, upon receiving the
notification (F8) may pop open a window with the date/time and the
number of the caller.
The rest of this section contains the details of the SIP messages in
Figure 3. The call flow details below assume that the SPIRITS
gateway is, for the purpose of this example, a SIP proxy that serves
as the default outbound proxy for the notifier and an ingress host of
the myprovider.com domain for the subscriber. The subscriber and
notifier may be in separate administrative domains.
F1: S->N
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP
that it wants to subscribe to (in this case, the TAA DP) and the
actual line it wants that DP armed for (in this case, the line
associated with the phone number 6302240216). This request
eventually arrives at the SIPRITS notifier, N, which authenticates it
(not shown) and sends a successful response to the subscriber:
F3: N->S
SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600
Accept: application/spirits-event+xml
Content-Length: 0
The notifier interacts with the SCF to arm the DP and also sends an
immediate NOTIFY towards the subscriber informing the subscriber of
the current state of the notification:
F4: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
F5: S->N
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
At some later point in time (before the subscription established in
F1 expires at the notifier), a call arrives at the number identified
in XML-encoded body of F1 -- 6302240216. The SCF notifies the
notifier (F6). Included in this notification is the relevant
information from the PSTN, namely, the phone number of the party
attempting to call 6302240216. The notifier uses this information to
create a SIP NOTIFY request and sends it to the subscriber. The SIP
NOTIFY request has a XML-encoded body with the relevant information
from the PSTN:
F7: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired
Accept: application/spirits-event+xml
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber>
</Event>
</spirits-event>
There are two important issues to note in the call flows for F7:
(1) The body of the NOTIFY request contains the information passed
to the SPIRITS notifier from the SCF. In this particular
example, this is the phone number of the party (3125551212)
that attempted to call 6302240216.
(2) Since the notification occurred, the subscription established
in F1 terminated (as evident by the Subscription-State
header). The subscription terminated normally due to the DP
associated with TAA firing (hence the reason code of "fired"
in the Subscription-State header). If the subscriber
wants to get notified of another attempt to call the number
6302240216, he/she should send a new SUBSCRIBE request to the
notifier.
The subscriber can take any appropriate action upon the receipt of
the NOTIFY in F7. A reasonable implementation may pop up a window
populated with the information contained in the body of F12, along
with a button asking the subscriber if they would like to re-
subscribe to the same event. Alternatively, a re-subscription could
be generated automatically by the subscriber’s UA based on his/her
preferences.
To complete the protocol, the subscriber also sends a 200 OK message
towards the notifier:
F8: S->N
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com
CSeq: 3300 NOTIFY
Content-Length: 0
5.3.14. Use of URIs to retrieve state
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It
is expected that most state information for this package is compact
enough to fit in a SIP message. However, to err on the side of
caution, implementations MUST follow the convention outlined in
Section 18.1.1 of [5] and use a congestion controlled transport if
the size of the request is within 200 bytes of the path MTU if known,
or if the request size is larger than 1300 bytes and the path MTU is
unknown.
5.4. Services through static DPs
We mentioned in Section 5.1 that the first trigger that fires during
call processing is typically a TDP since there isn’t any pre-existing
control relationship between the SSF and the SCF. Some Internet
hosts may have expressed an interest in executing services based on
TDPs (through an a-priori arrangement, which is not a part of this
specification). Thus, the PSTN will notify such hosts. To do so, it
will send a SIP request (typically an INVITE) towards the Internet
host. The body of the SIP request MUST contain multi-part MIME with
two MIME components: the first part corresponding to the normal
payload, if any, of the request; and the second part will contain
SPIRITS-specific information (e.g., the DP that fired). Responses to
the INVITE request, or subsequent SUBSCRIBE messages from the
Internet host to the PSTN within a current call context may result in
EDPs being armed.
5.4.1. Internet Call Waiting (ICW)
ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
Pre-SPIRITS implementations of ICW are detailed in [10]. However, as
the document notes, while a diversity of implementations exists,
these implementations are not interoperable. At the time [10] was
published, the industry did not have the depth of experience with SIP
as is the case now. The use of SIP in [10] does not constitute
normative usage of SIP as described in [5]; for instance, no mention
is made of the SDP (if any) in the initial INVITE (especially since
this pertains to "accept the call using VoIP" case). Thus this
section serves to provide a normative description of ICW in SPIRITS.
The description of ICW is deceptively simple: it is a service most
useful for single line phone subscribers that use the line to
establish an Internet session. In a nutshell, the service enables a
subscriber engaged in an Internet dial-up session to
o be notified of an incoming call to the very same telephone line
that is being used for the Internet connection,
o specify the desirable treatment of the call, and
o have the call handled as specified.
5.4.2. Call disposition choices
Section 2 of [10] details the call disposition outcome of a ICW
session. They are reproduced here as a numbered list for further
discussion:
1. Accepting the call over the PSTN line, thus terminating the
Internet (modem) connection
2. Accepting the call over the Internet using Voice over IP (VoIP)
3. Rejecting the call
4. Playing a pre-recorded message to the calling party and
disconnecting the call
5. Forwarding the call to voice mail
6. Forwarding the call to another number
7. Rejecting (or Forwarding) on no Response - If the subscriber
fails to respond within a certain period of time after the dialog
box has been displayed, the incoming call can be either rejected
or handled based on the treatment pre-defined by the subscriber.
It should be pointed out for the sake of completeness that ICW as a
SPIRITS service is not possible without making the SCP aware of the
fact that the subscriber line is being used for an Internet session.
That awareness, however, is not a part of the ICW service, but solely
a pre-requisite. One of the following three methods MUST be utilized
to impart this information to the SCP:
A. ICW subscriber based method: the ICW client on the subscriber’s
PC notifies the SCP of the Internet session by issuing a SIP
REGISTER request.
B. IN based method: SCP maintains a list of Internet Service
Provider (ISP) access numbers for a geographical area; when one of
these numbers is dialed and connected to, it (the SCP) assumes
that the calling party is engaged in an Internet session.
C. Any combination of methods A and B.
ICW depends on a TDP to be provisioned in the SSP. When the said TDP
is encountered, the SSP suspends processing of the call and sends a
request to the SPIRITS-capable SCP. The SCP determines that the
subscriber line is being used for an Internet session. It instructs
the SPIRITS notifier on the SCP to create a SIP INVITE request and
send it to the SPIRITS subscriber running on the subscriber’s IP
host.
The SPIRITS subscriber MUST return one of the possible call
disposition outcomes catalogued in Section 5.4.2. Note that outcomes
1 and 4 through 7 can all be coalesced into one case, namely
redirecting (using the SIP 3xx response code) the call to an
alternative SIP URI. In case of 1, the URI of the redirected call
MUST match the very same number being used by the customer to get
online. Rejecting the call implies sending a non-2xx and non-3xx
final response; the remaining outcomes result in the call being
redirected to an alternate URI which provides the desired service
(i.e., play a pre-recorded announcement, or record a voice message).
Further processing of a SPIRITS notifier when it receives a final
response can be summarized by the following steps:
1. If the response is a 4xx, 5xx, or 6xx class of response,
generate and transmit an ACK request and instruct the SSP to play
a busy tone to the caller.
2. Else, for all 3xx responses, generate and transmit an ACK
request, and compare the redirected URI to the subscriber’s line
number:
2a. If the comparison indicates a match, instruct the SSP to
hold onto the call for just enough time to allow the SPIRITS
subscriber to disconnect the modem, thus freeing up the line;
and then continue with normal call processing, which will
result in the subscriber’s phone to ring.
2b. If the comparison fails, instruct the SSP to route the
call to the redirected URI.
3. Else, for a 2xx response, follow the steps in section 5.4.3.
5.4.3. Accepting an ICW session using VoIP
One call handling option in ICW is to "accept an incoming call using
VoIP". The SPIRITS notifier has no way of knowing a-priori if the
subscriber (callee) will be choosing this option; nonetheless, it has
to account for such a choice by adding a SDP in the body of the
INVITE request. A possible way of accomplishing this is to have the
SPIRITS notifier control a PSTN gateway and allocate appropriate
resources on it. Once this is done, the SPIRITS notifier adds
network information (IP address of the gateway and port numbers where
media will be received) and codec information as the SDP portion of
the body in the INVITE request. SPIRITS requires the DP information
to be carried in the request body as well. To that extent, the
SPIRITS notifier MUST also add the information associated with the
TDP that triggered the service. Thus, the body of the INVITE MUST
contain multi-part MIME, with two components.
The SPIRITS notifier transmits the INVITE request to the subscriber
and now waits for a final response. Further processing when the
SPIRITS subscriber returns a 200 OK MUST be handled as follows:
On the receipt of a 200 OK containing the SDP of the subscriber’s
UA, the SPIRITS notifier will instruct the SSP to terminate the
call on a pre-allocated port on the gateway. This port MUST be
correlated by the gateway to the SDP that was sent in the earlier
INVITE.
The end result is that the caller and callee hold a voice session
with part of the session occurring over VoIP.
6. Non-call related events
There are network events that are not related to setting up,
maintaining, or tearing down voice calls. Such events occur on the
cellular wireless network and can be used by SPIRITS to provide
services. The SPIRITS protocol requirement explicitly includes the
following events for which SPIRITS notification is needed
(RFC3298:Section 5(b)):
1. Location update in the same Visitor Location Register (VLR)
service area
2. Location update in another VLR service area
3. International Mobile Subscriber Identity (IMSI) attach
4. Mobile Subscriber (MS) initiated IMSI detach
5. Network initiated IMSI detach
6.1. Non-call events and their required parameters
Each of the five non-call related event is given a SPIRITS-specific
mnemonic for use in subscriptions and notifications.
Location update in the same VLR area
SPIRITS mnemonic: LUSV
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
Cell-ID: A string used to identify the serving Cell-ID. The actual
length and representation of this parameter depend on the particulars
of the cellular provider’s network.
Location update in different VLR area
SPIRITS mnemonic: LUDV
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
IMSI attach
SPIRITS mnemonic: REG
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
MS initiated IMSI detach
SPIRITS mnemonic: UNREGMS
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
Network initiated IMSI detach
SPIRITS mnemonic: UNREGNTWK
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
6.2. Normative usage
A subscriber will issue a SUBSCRIBE request which identifies a set of
non-call related PSTN events it is interested in getting the
notification of. This set MAY contain exactly one event, or it MAY
contain multiple events. The SUBSCRIBE request is routed to the
notifier where it is accepted, pending a successful authentication.
When any of the events identified in the set occurs, the notifier
will format a NOTIFY request and direct it towards the subscriber.
The NOTIFY request will contain information pertinent to the one of
the event whose notification was requested.
The dialog established by the SUBSCRIBE persists until it expires
normally, or is explicitly expired by the subscriber. This behavior
is different than the behavior for subscriptions associated with the
"spirits-INDPs" package. In the cellular network, the events
subscribed for may occur at a far greater frequency than those
compared to the wireline network (consider location updates as a
cellular user moves around). Thus it is far more expedient to allow
the subscription to expire normally.
When a subscriber receives a NOTIFY request, it can subsequently
choose to act in a manner appropriate to the notification.
The remaining sections fill in the specific package responsibilities
raised in RFC3265 [3], Section 4.4.
6.3. Event package name
This document defines two event packages; the first was defined in
Section 5.3. The second package, defined in this section is called
"spirits-user-prof". This package MUST be used for events
corresponding to non-call related events in the cellular network.
All entities that implement the SPIRITS protocol and support the
non-call related events outlined in the SPIRITS protocol requirements
(RFC3298:Section 5(b)) MUST set the "Event" header request header[3]
to "spirits-user-prof." The "Allow-Events" general header [3] MUST
include the token "spirits-user-prof" as well.
Example:
Event: spirits-user-prof
Allow-Events: spirits-user-prof, spirits-INDPs
6.4. Event package parameters