Subject: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protocol

From: [email-masked]
Date: Wed, 19 Jul 2000 14:55:06 +0200

After reading the IN- and PINT-related Requirements for SPIRITS Protocol, I
have the following comments/questions.

In section 4 "IN Requirements", page 3, item 3, it is suggested to match
each event with a separate message that corresponds to it. I am not against
this proposal, but I do not understand why this is better than having one
message for all events. This looks like, in INAP CS2, the choice of sending
DP specific operations versus an EventReportBCSM with information about the
detected event (ITU-T accepts both, while ETSI only the latter). Can you
help me to understand it?.

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.
b) Pass parameters associated to the EDP. For example a no answer timer can
be passed in to EDP o_No_Answer.

For example a "C : SUBSCRIBE <Event>, <Mode>, <DP specific params>" could
work.

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?. Maybe I do not understand properly the I-D ?.

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 ?.

I hope my comments are helpful.

Best Regards,

Jorge Gató
Airtel Móvil

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

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 21 Jul 2000 19:23:55 -0400

> help me to understand it?.

A good question and the right observation. Ray just responded to that, and I
agree with Jorge (and agreed with Ray) on having one message, as far as the
transport protocol is concerned. My idea was to ensure that we pick the ITU
standard parameters but avoild--by all means--choosing application context
options. It is obvious that the statement I wrote in the requirements caused
confusion and it will need to be rewritten. 

> environment. I understand that both methods to arm events can be applicable

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.

> For example a "C : SUBSCRIBE <Event>, <Mode>, <DP specific params>" could

Yes!

> as a requirement?.

Absolutely, they should! Please add this material.

> Maybe I do not understand properly the I-D ?.

You do, and perfectly so! Just more work needs to be done, and your help is
sought.

> (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.

> I hope my comments are helpful.

Very helpful (and they demonstrate your top-notch expertise on the subject!). I
hope you are coming to the next IETF meeting so I can shake your hand in
Pittsburgh. On behalf of the authors' team, I am inviting you to co-author the
future version of this I-D.

With many thanks,

Igor