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

Dale

Thank you for taking the time to comment on this draft.

>I'm mystified by what this draft is trying to accomplish.  If a SIP
>user wishes to contact an Information Service, he can just issue an
>INVITE to the service's URI.  This draft seems to assume that all
>information services are integrated into the fabric of the transport
>network, which is a poor architectural decision with adverse economic
>consequences.

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. Also, it would simplify the
connectivity to such services via SIP, rather than requiring VSPs to
implement customized solutions or hand off via a PSTN interface. Going
forward, it would allow DA providers to deploy more advanced services by
taking advantage of SIP, rather than simply replicating what is
currently possible on the PSTN. I am referring to "DA" here, but there
are other services to which this all applies. We would hope that the end
results of this would result in positive economic consequences.

>At the very least, you can correct the first sentence of the abstract:
> 
>   Information Services are services whereby information is provided by

>   the network in response to user requests
> 
>By definition, a network doesn't *provide* information, it
>*transports* it.  Network endpoints provide information.

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.

>OK, I'm being cranky here.  But if all this apparatus is necessary,
>there must be some requirements that I don't see stated clearly.

Not at all, we need these kinds of comments to make sure things are
clear. Again, in the next revision of the draft, we'll make sure these
requirements are very clear. 

The draft covers several areas, but a good amount of text is devoted to
handling different network scenarios, which are driven by different
business relationships. It probably does seem like a lot of complexity,
so I'll give some explanations here. 

The draft is inclusive of several business models. It includes the
Service URN, so that a UA could make use of that mechanism to resolve
the provider's URI to make the call directly as you indicate, if the
infrastructure to support that is in place. Also, if a user's provider
has the ability to provide such services natively, then little else is
needed to get the caller to the service. So the simple case is included.

Services like DA require specialized infrastructure as well as
personnel, so many voice providers farm this out to third parties. The
draft includes the model where the subscriber's provider has a business
agreement with a separate DA provider. This is commonplace today both in
the PSTN and also with VOIP providers. This is what we are calling the
"direct" third party provider in the draft. An example would be provider
A has a relationship with DA provider C to handle DA queries for its
customers.

The draft is also inclusive of the model where the subscriber's provider
for whatever reason does not have any agreement with a DA provider. But
it does have an agreement with another provider, which in turn has such
agreements. This facilitates among other things the "little guy" being
able to offer such services to his customers without having to have an
arrangement directly with a DA provider. This is what we are calling the
"indirect" third party provider. An example would be where provider A
has an agreement with provider B for any services it cannot provide
natively, including DA. Provider B might provide some services natively,
and might farm others out. For instance it might farm out DA to provider
C.

Services like DA are usually branded - the identity of the caller's
provider impacts how the call is processed, based on the agreement
between the caller's provider and the DA provider. One example is that
providers want the DA provider to play a custom greeting when providing
service to their customers. So, a subscriber of provider A makes a 411
call for DA, and provider A hands the call off to DA provider C with
whom it has such arrangements. Provider A wants the customer to be
greeted with some custom greeting like "thank you for using provider A".
Also, provider A may have contracted for other services such as call
completion, where once the requested listing is provided, the DA
provider offers to complete the call to that party, so the user need not
remember the number, hang up, and then dial the number. Another example
might be that DA providers could have different default languages for
each provider with whom they have agreements (this would not rule out a
per subscriber language preference). 

In the indirect model, we allow for the processing to take account of
both the caller's provider as well as the provider with the direct
relationship to the DA provider. 

The draft is not trying to weave these complicated relationships into
the fabric - it just needs be inclusive of them as well as the simple
case. It sounds like a lot of complexity, but in the end we are just
trying to specify ways to use existing SIP mechanisms to support them.
>From my original email, this currently comes down to specifying the use
of P-Asserted-Identity and Via headers, with a few constraints. 

We need to make sure this all comes through clearly in the draft. I'm
hoping that the reduction in scope in the next revision will help to
make this come through more clearly.

I would also appreciate any technical comments on the questions in my
previous post:

========================================================================
======

I am seeking comments on
draft-haluska-sipping-directory-assistance-01.txt. Specifically,

1. Assuming that the providers involved agree, does it seem reasonable
to specify the use of the domain-name format of P-Asserted-Identity, in
order to determine the identity of the home provider? This seems to make
sense, especially given the fact that SBCs can break SIP Identity, as
pointed out in the recent identity coexistence draft.

2. Does it seem reasonable to maintain a list of values for "via"
headers expected from providers from which the Operator and Information
Services Provider (OISP)  would expect to receive calls, to identify the
provider who is sending the call to the OISP? These would be providers
with whom the OISP has a pre existing relationship.

3. For identifying the caller's terminal capabilities and
characteristics, we plan to specify  the use of RFC 3840 (indicating UA
capabilities in SIP) when it is supported - it is not in the current
revision of the draft. Where it is not supported, the session either
needs to do without this information, or some lookup (e.g. HSS in am IMS
environment) could be done.

4. We plan to reduce the scope - it will not normatively define an
architecture (it will still describe one for the purposes of discussion)
and concentrate more on identifying existing SIP mechanisms for
conveying the required information, and will include additional call
flows. 

Any comments are greatly appreciated.