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

From: [email-masked]
Date: Thu, 20 Jul 2000 11:30:58 +0100

Jorge wrote:

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

To my understanding the DP Specific Operations work very slowly as the AIN
protocol has a very large message set.

ETSI support the alternative because it is flexible and extensible without
constantly re-inventing the message handling devices. Hence it may be optimised
to run faster with cheaper extensions.

What is a Semantic Overload of the Protocol Message? I would support that the
IETF uses a mechanism closer to the Event Report BCSM (generic Event
Notification) otherwise the SPIRITS Proxy and the SPIRITS Server message handler
will be very complex.

Ray Forbes

[email-masked] on 19/07/2000 13:55:06

Please respond to [email-masked]

                                                              

 To:      [email-masked]                         
                                                              
 cc:      (bcc: Raymond Forbes/MAIN/MC1)                      

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

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 18:11:29 -0400

[email-masked] wrote:
...

> to run faster with cheaper extensions.

Oh no! If we discuss this any further, we will restart the 10 year old "US vs.
Europe" struggle in ITU-T.  I am sorry I (unintentionally) triggered it, so to
fix the situatio I am not commenting. (In ITU-T I would have been compelled
to...)

> 
> What is a Semantic Overload of the Protocol Message?

It is a situation in which a syntactic element (a name of a parameter or a
message) can have different values (belonging to different domains) depending on
the context. For example, a parameter called "spirits" could in one context have
a value from a set {beer, wine, vodka, gin}, and--in another context--a value
from a set {gremlin, ghost, poltergeist, spook}. As for the message as the
whole, overload shows its spooky head when it can have different sets of
parameters, again depending on the context. 

>I would support that the

I fully agree with Ray. I know my tongue will be cut out by the esteemed
chairmen for talking about SIP prematurely, but I think that the SIP/PINT
mechanism (possibly augmented) for S...BSCRIBE/NOTIFY is what ought to be used
for dynamic setting/notification of DPs, and INVITE for SPIRITS invocation on
triggers. 

Igor