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

From: [email-masked]
Date: Tue, 11 Feb 2003 10:00:25 +0530

Hi Igor,
     The functionality is there to serve the same purpose only. Why to
re-invent the wheel. If there is something lacking to serve the purpose, the
intent can be enhance the existing functionalities.
Regards
Dhiraj

Igor Faynberg <[email-masked]> on 02/10/2003 08:36:43 PM

Please respond to [email-masked]

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

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

I don't think there is much useful for us in the  CUSF specification, but all
the information there is can be found in ITU-T Recommendations Q.1224 and
Q.1228.

Igor

"Vijay K. Gurbani" wrote:
>
> 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

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

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 11 Feb 2003 12:04:25 -0500

Dhiraj,

I agree. (By the way, my note was concerning CS-2, where not much except the
definition was present. As Bruno suggested, we would need to look at CS-3, where
indeed the CUSF DPs were defined.)

Igor