[Speermint] Directory assistance draft/peering for services

Hello all, 

I  am seeking comments on
draft-haluska-sipping-directory-assistance-01.txt, which I've already
posted to the SIPPING ML and gotten some comments on. I was thinking
that the SPEERMINT WG might have the expertise to help answer some
specific questions I have, and perhaps for general comments as well.

First, to make a long story short, what this draft is basically trying
to accomplish is to specify how existing SIP mechanisms can be used to
implement Information Services, which include Directory Assistance. This
would promote interoperability, would facilitate connectivity via SIP as
an alternative to TDM, and would facilitate the development of more
advanced services. 

Why post this to SPEERMINT? DA services are often provided as a
wholesale service, and therefore calls could potentially traverse
multiple providers between the caller and the DA provider. The DA
provider needs to know the identities of at least the caller's "home
provider" and the "last-hop" provider before the DA provider. These are
used to influence call processing (e.g. branded services/announcements)
in a number of ways, as well as to facilitate accounting. I am thinking
that providers involved in peering might have reasons to care about the
various providers a call may have traversed.

1. Currently, the draft specifies that the "home provider" would insert
a P-Asserted-Identity header using the domain-name format, so that the
home provider's identity could determined from the domain name.
Assuming that the providers involved agree, does this seem reasonable?
This seems to make sense, especially given the fact that SBCs can break
SIP Identity, as pointed out in the recent SIP identity coexistence
draft.

2. For the "last-hop" provider, we are specifying that the DA provider
would keep a list of values of "Via" headers from boxes from which it
would expect to receive calls, so that based on the Via value we can
determine who sent in the call.

3. We are thinking it might be necessary to know the identity of some
other providers which are neither the home provider nor the last-hop,
and thinking that SIP History-Info could be used for this.

            Has anyone encountered the need to do this in a peering
environment, or otherwise?

            Does the use of SIP History-Info for this seem appropriate?

            Does this seem like it would be generally useful for
SPEERMINT?

4. The DA provider needs to know the calling terminal's capabilities and
characteristics, so it  would know whether sending e.g. a text message
or initiating a multimedia session (e.g. to play a video clip) is
possible. 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 an
IMS environment) could be done.

5. In addition to these questions, I've been wondering whether anyone
has thought about how the SPEERMINT architecture might be used for
peering for the purpose of providing services, rather than only for
providing call terminations?  I'm wondering how well something like this
would mesh with/benefit from what the SPEERMINT WG is trying to do. If
some arrangement existed whereby many  VSPs might be served by multiple
DA providers (or providers of other types of services), then something
more complex than simple bilateral agreements would be needed. 

Note that in a thread on the SIPPING ML (between 9 Jan and 15 Jan 2007)
there seemed to be some recognition that at least some of what's in the
draft might be more widely applicable than just this service. 

Note that we do plan to reduce the scope of the draft in the next
revision - 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. 

Thanks much

John Haluska