Subject: Re: [SPIRITS] Representing non-call related events

From: [email-masked]
Date: Wed, 5 Feb 2003 09:20:10 +0530

Vijay,
     Are you trying to define the way supplementary services shall work
in the SPIRITS model ?
Regards
Dhiraj

"Vijay K. Gurbani" <[email-masked]> on 02/04/2003 11:18:36 PM

To:   "Vijay K. Gurbani" <[email-masked]>
cc:   SPIRITS list <[email-masked]> (bcc: Dhiraj Malhotra/HSS)

Subject:  Re: [SPIRITS] Representing non-call related events

Folks:

Regarding the discussion below, it was suggested to me in a private
email that the CUSF functional entity of IN-CS2 be looked into.

Is there anyone on the list familiar with this and willing to pitch
in some time?  Any discussion (and help) will be extremely fruitful, I
think...

Thanks,

- vijay

Vijay K. Gurbani wrote:
> Folks:
>
> I want to start a discussion about how to best represent non-call
> related events in the SPIRITS XML payload.
>
> Non-call related events include those concerned with mobility,
> location, SMS, etc.  Note that no DP is involved here; in fact,
> SPIRITS has a Event token called 'spirits-user-prof' for these
> types of events.
>
> One way to represent these events to have a specific element
> called <SUP> for such SUPplementary services.  Thus, in order
> to transform a SMS into an IM, the SUBSCRIBE payload could
> conceivably contain:
>
>     <spirits-event>
>          <SUP app="SMS"/>
>          <Mode>Notify</Mode>
>          <CallingPartySubaddress>16302240216</CallingPartySubaddress>
>     </spirits-event>
>
> However, that puts us in the dubious position of specifying all
> the possible supplementary services in SPIRITS -- which is
> definitely NOT what we want to do.  One way to combat that problem
> is to say that the value of "app" attribute is a token, the details
> and semantics of which are dependent on the token.
>
> How do we handle location?  Maybe we can scour geopriv for some
> answers (see
> http://www.ietf.org/internet-drafts/draft-daviel-html-geo-tag-05.txt)
> as well as Daniel Moreno's draft on mobility events management
> (http://www.ietf.org/internet-drafts/draft-ietf-spirits-mobility-00.txt)
>
> Any other ideas?  Any thoughts would be appreciated.
>
> Thanks,
>
> - vijay

--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Feb 2003 09:02:13 -0600

>      Are you trying to define the way supplementary services shall work

No; I think the word 'supplementary' in my email may have been
mis-interpreted.  I understand that 'supplementary' is a well defined
term in the PSTN/ISDN/GSM domain.

In SPIRITS, I want to be able to provide services based on network
events that are not part of call setup, teardown, or maintenance.  For
instance, in the wireless network, mobility management events are of
prime interest to us as a service enabler (some work has been done by
Daniel Moreno in cataloging these for SPIRITS, see
http://www.ietf.org/internet-drafts/draft-ietf-spirits-mobility-00.txt).

But there are a lot of other events happening that we can exploit.
For instance, a parent can subscribe to the event of a college bound
offspring's pre-paid card balance falling below a certain limit in
order to replenish the account (or rescind it, as the case may be).
Not to mention my SMS->IM service.

The question is how to represent a set of such events in an extensible
manner without tying the SPIRITS protocol to a particular service
instance.

Bruno Chatras' email on this topic (which was CC'd to the list) helps
as well; I need some time to understand the points he is making before
posting a response...

Thanks,

- vijay