Hello,
I would tend to agree with Ludovic.
This usecase is quite common where people trust the records of a customers phone number more than having an alignment of the geographic address between customer and CSP.
Postal addresses can change or a customer may have a different view of their address as opposed to what is recorded (due to change of use of premises or reorganisation of post codes).
Also when people are ordering services for a premises they are moving to, a phone number might be more reliable than their knowledge of their soon to be new address.
However, with the growth of VoIP services, associations of phone numbers with locations is becoming something which will be less reliable.
So what is the API actually specified to support in this case?
I have read the specification a few times and some of the descriptions are a bit obscure.
From past experience I see the following usecases.
1) Provide some form of geographic location as a statement of the place for the intended installation and query what can be installed there or check whether a particular service can be installed.
2) Provide the identity of an existing service and query what upgrades or replacements are available or whether a particular upgrade can be done to that service.
3) Provide the identity of an existing service as a proxy for a geographic location (like a working telephone number that also happens to be in the proposed installation location) and then ask what can be provided in the same building (a second line or something unconnected at all with the serviced referenced) alongside that service as an addition.
4) Provide identity of an existing service as a proxy for a network termination point, copper line or physical fibre and ask what other services can sit on that physical infrastructure alongside the services already provided (like install VDSL/ADSL on a copper pair identified by its working phone number).
The important thing is to make sure the correct roles associated with the correct attributes so one does not mistake install new infrastructure for upgrade/extend existing infrastructure etc.
I think that is perhaps a worthwhile thing to make explicit in the specification at some time in the future.
------------------------------
Derrick Evans
------------------------------
Original Message:
Sent: Mar 04, 2022 12:07
From: Ludovic Robert
Subject: TMF645 - query based on existing service
Hello Ján
Humm not easy.
For me your intend is to provide a 'where' and to do that you provide an indirect information. So I will stick to place use and I will probably opt for your first option with a 'specific' @type like 'resourceLocation'.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Mar 03, 2022 05:29
From: Ján Krištof
Subject: TMF645 - query based on existing service
Collegues,
I have one usecase to solve, and I would appreciate your advice. We have usecase, when in QueryServiceQualification there is "place" not defined as installation address, but "place" is defined by parameter of existing service at given place/location. For example, phone number of fix line, ServicePoindID which represent endpoint at customer location. (Get qualification based on exact service is much more precise in some case (line speed upgrade) and it's also convinient for consumer of TMF645) Question is, how to create such request (searchCriteria).
Option 1 - use "place", use role, @type to distinquish for place defined by service parameters
Option 2 - use "service" parameters and related objects (my worries here are, that this will act as filter and in response I will have only the same service as was defined in searchCriteria)
Option 3 - do you see other ways how to do it?
Thanks
Jan
------------------------------
Ján Krištof
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------