Re: [Sipping] seeking comments on draft-haluska-sipping-directory-assistance-01.txt

[[e-mail]]

   From: "Haluska, John J" <[e-mail]>

   Currently, services like Directory Assistance (DA) and Operator Services
   often use traditional interfaces that are challenging to evolve. What we
   are ultimately trying to do is specify how these existing services  and
   future advanced DA services could be implemented in a standardized way
   using SIP interfaces. This would simplify the integration efforts for
   the vendors and service providers.

OK, so much of this draft is "inward facing", toward the
community/market of existing DA vendors/providers, and much of what it
addresses is migrating an existing architecture to the SIP universe.
Hence, when a naive "outside" reader (e.g., me) reads it, it appears
to be a straitjacket, it documents only one approach to implementing
DA, but that's because what it documents is parallel to the existing
DA infrastructure.

   Definitely in the next revision, we plan to reduce the scope,
   concentrating on solutions to the technical problems. The abstract would
   be updated, and your comments are well taken. The draft definitely does
   not mean to imply that the services are woven into the fabric of the
   transport network, if it comes across that way then we need to change
   it. Nor should it come across as implying that layer 3 entities or the
   network itself are providing these services. So the wording will
   definitely change.

   The draft is inclusive of several business models. [...]  The draft
   includes the model where the subscriber's provider has a business
   agreement with a separate DA provider. [...]

How does this relate to what I expect to be the most common business
model, where the user contracts with a DA provider directly, and the
(transport) service provider is used only to move bits between the
two?  (This would be somewhat like long-distance calling in the US,
which is typically not subcontracted through one's local service
provider.)

(I would expect the commonest exception to the above to be when the
service provider has bundled DA services and offers them at a
discounted price.)

Perhaps another way to look at this is this:  You're working on two
problems, which may be intertwined:  One is the technological
specifics of providing DA services, but the other is the technological
specifics of supporting various business models (really, charging
schemes).  I suspect the DA services themselves are fairly
straightforward, but the charging schemes are a nearly virgin area of
research.  The interesting consequence of looking at it this way is
that the charging scheme work may be applicable to a much wider range
of problems than you are addressing now.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP