Subject: RE: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Proto co

From: "Slutsman, Lev A, ALSVC" <[email-masked]>
Date: Thu, 24 Aug 2000 11:29:41 -0400

Dear Team,
I can not go, but could we have a conference call?
Regards, Lev.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 24, 2000 11:27 AM
To: [email-masked]
Subject: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS
Protoco

Hi Igor and SPIRITS floks,

I guess I should introduce myself (I should have done it before, please
accept my apologies).
I work for Airtel  Móvil (a fix/mobile/ISP company part of the
Vodafone-Airtouch group)
in Madrid, Spain.

I am leading the group responsible for "Network Intelligence" (we have
changed the name from
"Intelligent Networks"). We both do service development (customised for our
specific needs),
some consultancy worl for the rest of the company for IN matters and look
into evolution and
standardisation issues.

Below is what I have had time to prepare so far. I hope you find it useful.
Please feel free to use
it and correct as you consider necessary.

Best Regards,

Jorge Gato

>> In section 4 "IN Requirements", page 4, the requirement to "subscribe"
>> to an event from the SPIRITS client is defined as "C : SUBSCRIBE
>> <Event>". I think that more parameters could be useful to:
>>
>> a) Determine if the EDP is going to be armed as EDP-R or EDP-N in
>> the IN environment. I understand that both methods to arm events can
>> be applicable to SPIRITS services.
>
>I agree that the explicit requirement for arming DPs is necessary. We
>should definitely add that to the requirements. But here are two fine
>points:
>
>1) The requiement that the SCP DPs be dynamically armed from the IP
>side is >something that must be supported (because it can be standardized
>only by) ITU-T. (I don't see much problem because this is where all
>implementations are going.) That is something that Hui-Lan should bring
>as the ISOC liaison to the next SG 11 meeting.
>
>2) I understand that the  S..CRIBE/NOTIFY works now much like setting
>EDP-N. Now, If a DP is set as an EDP-R, would it mean invocation of
>another service or mere continuation of a previous one? (I don't know
>the answer. Let us think.) After all, the SPIRITS proxy-to-server
>(i.e., SCP) relation is NOT the same as that of the SSP-to-SCP. I don't
>see right now a need for EDP-R, but that does not mean there is not any.
>Let us discuss.

I am not sure if we are talking about the same thing. I understand that
the "SUBSCRIBE" message is sent from the SPIRITS Proxy to the SPIRITS
client, to be mapped to something to be sent to the Service Control in
the SCP. Alternatively the client itself could decide to subscribe to
an event without action of the server (this can be the case of automatic
call dispositions handled without the server participation).

The scenario can be as follows:

SPIRITS  -> SUBSCRIBE (event) -> SPIRITS
 Proxy                       Client
                              |
                    Whatever (out of scope of SPIRITS)
                              |
                              V
                              SCP
                              |
                    RequestReportBCSMEvent (INAP CSX)
                              |
                              V
                              SSP

What I mean with setting an EDP-R is that the SPIRITS Server could
require to the IN service associated to keep control of the call
after the action decided (requiring an EDP-R to be armed in the
switching system via the SCP).

You are right that for the "milestone" services this is not needed,
but it could be useful for future services.

An example could an enhanced Internet Call Forwarding where the
service wants to make sure the call is accepted by the diverted to
party. In this case the SPIRITS service would need to arm EDPs in
Request mode to be able to re-route the call in case of failure (for
example to the Voice Mail or to another number selected by the user).

The difference with the EDP-N case is that the SPIRITS server can take
an action involving modifying the related PSTN signalling (like
re-routing calls). Thus:

a) With EDP-N, when the SPIRITS service receives an event, all it can
do is notify the IP Host, update statistical counters or end
processing.

b) With EDP-R, the SPIRITS service can order re-routing of the call
(and eventually could order any action allowed by IN standards, like
order applying announcements or creating a multi-leg call).

Of course, another option is to always arm EDP-Rs, but this would
waste resources in cases where only backwards notification is desired
(for example, an abandon EDP-N may be wanted to release resources in
the SPIRITS entities).

I guess that (if SIP is seleted) some indication about the type of event
armed (Request or Notify) chould be needed in SUBSCRIBE and probably
NOTIFY.

The need to set DP-R has been already been identified in your document.
In section 5, there is as reference of the mechanism to register to the
SPIRITS service. In page 5 (just before the "Methodology" section) there
is a reference of the need to use SUBSCRIBE/NOTIFY PINT building blocks
for the purpose of setting DPs/getting DP event notifications. If the
complete mechanism to register is put in place, it requires setting
a TDP-R in the switch. Thus, there should be a way to subscribe to a
Request type event (in this case a static event, a TDP, not related
to a specific call).

Thus, the SUBSCRIBE message could look like

SUBSCRIBE <Event>, <Mode>, <Parameters>

where

i) Mode could be:

- dynamic-request (EDP-R)
- dynamic-notify (EDP-N)
- static (TDP-R) -I do not see the need to arm TDP-N-.

ii) Event could be all CS2 DPs, although I guess not all of them would be
used. Since SPIRITS is intended to run services in the IP world to
assist PSTN services, I see the following CS-2 DPs as applicable:

- origination_attempt_authorized (the SPIRITS service can control call
attempts, e.g. to limit calls during specific time periods)
- collected_information (for SPIRITS outgoing call screening)
- analyzed_information (for SPIRITS outgoing call screening)
- (O & T) answer (to release SPIRITS resources after the call is
complete)
- O_term_seized (to release SPIRITS resources after the call is
complete)
- (O & T) no_answer (to re-route a call)
- (O & T) busy (to re-route a call and for ICW)
- route_select_failure (to re-route a call)
- (O & T) mid_call (for SPIRITS service to assist a midcall action)
- (O & T) abandon (to release SPIRITS service resources)
- (O & T) disconnect (to release SPIRITS service resources)
- termination_attempt_authorized (needed for SPIRITS "milestone" services)
- facility_selected_and_available (could be used alternatively for SPIRITS
Internet Caller-ID)

However, the only DPs which I see needed for the SPIRITS "milestone"
services
are:

- Termination Attempt Authorized (for Internet Caller-ID).
- Facility_selected_and_available (for Internet Caller-ID instead of the
TAT).
- T_busy (for Internet Call Waiting and Internet Call Forwarding)

iii) Parameters should be event specific. I see the need for:

- timer (for no answer)
- midcall control info (for mid_call)
- number of digits (for collected_information)

>>
>> Besides, I miss more protocol requirements between the SPIRITS client
>> and proxy. There is nothing about the signalling flow for the SPIRITS
>> service>> (only the event notification and registration parts are
>> covered). For example, how will the SPIRITS proxy send the SPIRITS
>> server dispositions about an incoming call to the SPIRITS client (so
>> it is sent later to the PSTN invoking network)?. I understand that
>> these requirements can be covered by existing protocols (e.g. SIP),
>> but should not they be specified as a requirement?.
>
>Absolutely, they should! Please add this material.

What I meant here is that the response message to the "Event Notification"
is
another requirement. In a case where the

a) The IP subscriber registers a SPIRITS service.
b) A call triggering the SPIRITS service is received (the event is
received).
c) The call disposition is sent.

the signalling flow could look like:

        |---->  REGISTER  ----->|
SPIRITS  |<----   EVENT    <-----|SPIRITS
 Proxy   |----> DISPOSITION ---->| Client
        |                   |
        |                   |  |
                              |
                              |
                              V
                              SCP
                              |
                              |
                              V
                              SSP

I see missing the call disposition part. Based on the benchmark services,
the
following ones are needed:

a) Accept the incoming call.
b) Reject the incoming call.
c) Redirect the incoming call.
d) Accept the call via VoIP (not included in SPIRITS architecture).

Again, we can think of using one message or several messages for each
option.
I personally would prefer using several messages:

a) S->P: <[Accept Call]>
b) S->P: <[Reject Call],[Cause]>
c) S->P: <[Redirect Call],[Redirection Destination]>

This alternative is also quite in the same line that the proposal Jörgen
and
Sören in "draft-bjorkner-spirits-vsua-00".

I understand that the option of accepting the call with VoIP is outside
SPIRITS
and should not be included here, but still we might want to add an option
to the
Accept Call case to indicate VoIP. What do you think ?.

>>
>> Finally, in regards to the Methodology I fully agree on the work needed.
>> However, reading the version of ITU-T CS2 specifications that I have
>> available (I am not sure if they are the latest ones) the parameters
>> indicated are not right. For example, I do neither see "Alerting
>> Pattern" being part of TerminationAttemptAuthorized nor
>> "DestinationRoutingAddress" (while many parameters are missing). Can you
>> double check ?.
>
>That was just an example, but I strongly suspect I have  screwed something
>up because I looked at one of my good old files instead of the final text
>of Q.1228. That will need to be corrected, of course.

The fields which I think are part of the CS-2 TerminationAttemptAuthorized
are

Call ID
begin dPSpecificCommonParameters:
____________
serviceAddressInformation (triggerType, misCallInfo, serviceKey)
bearerCapability
calledPartyNumber
callingPartyNumber
callingPartysCategory
iPSSPCapabilities
iPAvailable
iSDNAccessRelatedInformation
cGEncountered
locationNumber
serviceProfileIdentifier
terminalType
chargeNumber
servingAreaID
serviceInteractionIndicators
serviceInteractionIndicatorsTwo
iNServiceCompatibilityIndication
uSIInformation
uSIServiceIndicator
forwardGVNS
createdCallSegmentAssociation
end dPSpecificCommonParameters
________
dialledDigits
callingPartyBusinessGroupID
callingPartySubaddress
callingFacilityGroup
callingFacilityGroupMember
originalCalledPartyID
prefix
redirectingPartyID
redirectionInformation
routeList
travellingClassMark
featureCode
accessCode
carrier
serviceInteractionIndicators
componentType
component
componentCorrelationID
bcsmEventCorrelationOD
CalledPartyBusinessGroupID
CalledPartySubaddress
CallingPartyBusinessGroupID
originalCalledPartyID
redirectingPartyID
redirectionInformation
routeList
travellingClassMark

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits