[Sipping] Some more thoughts on draft-haluska-sipping-directory-assistance-01.txt

[[e-mail]]

* This draft touches on a lot of interesting matters, many of which seem
to be advances in the state of the art.

This draft seems to intertwine at least 3 seperable issues:

- the execution of an OIS service

- the billing of an OIS service 

- determining that an abstract OIS request is such, and determining
  which OISP endpoint to route it to

In the PSTN, these are tightly tied together, but I expect that in the
SIP world, they will quickly become disaggregated.  I think the draft
would be more useful if these issues were identified for the reader
and explicitly treated as separable.

Of these, the execution of OIS services is probably the best-defined
in current SIP practice.  (Except for the case of wanting to re-route
the caller's dialog to the OISP after the caller's UA completes a call
to a specified third party -- I don't think there is current SIP CC
for that operation.)

* Is this draft intended to only apply to the IMS sub-world, or is it
intended for broader applicability?

This should be stated.

* The range of business models considered seems to be quite narrow:

   There are several network scenarios which must be supported: 

   Services are provided by the caller's home provider. 

   Services are provided a third party provider which has direct SIP 
   layer connectivity as well as business relationships with the 
   caller's home provider. 

   Services are provided a third party provider which has no direct SIP 
   layer connectivity and no business relationships with the caller's 
   home provider. 

For instance, consider "Services are provided a third party provider
which has direct SIP layer connectivity but no business relationships
with the caller's home provider. " and "Services are provided a third
party provider which has no business relationships with the caller,
but does have a business relationship with another third party
provider which has a direct business relationship with the caller."
And I expect a little thought could construct many other cases.  Any
proposed mechanisms should work in a broad range of business models.

* On page 22:

   It is assumed that the right-hand side of the caller's SIP URI 
   unambiguously defines the caller's home provider. 

I expect that this will not be true for long, even in "walled garden"
environments -- For e-mail, businesses and even individuals have
clamored for "vanity" domain names, and large commercial e-mail
providers support such services.  I expect that vanity SIP domain
names will be popular from Day 1.  And if there is any possibility
that an organization's SIP service can be provided by multiple network
providers, the SIP domain name will not be a reliable provider
identification.  (This will probably be true for all organizations
with multiple physical locations.)

It may be necessary to have the network assert a "network identity"
for the caller which is bound to the network service provider *for
this call*, and which is not the same as the caller's AOR or From
header.  This doesn't seem to be difficult, but has to be planned for.

* The resolution of an OIS service request to the actual OISP is an
interesting question and deserves more attention.

Currently, the SIP caller accesses an OIS by a SIP URI that identifies
the OSIP.  But this draft assumes (without stating) that the caller
specifies a URI that specifies the nature of the service without
identifying what OISP should provide it, a URN rather than a URL.  So
there is (1) a space of URIs that provide such service
identifications, and (2) a resolution process that converts these URIs
to routable URIs (before the call escapes the initial SIP provider's
network).

This is a very interesting question, and as far as I know, there is no
standardized architecture for providing such resolution.  But this
draft implies such an architecture without giving any of the details.

* The draft refers to the OSIP querying the caller's UA to determine
its capabilities.  But it should also be able to query the network
path to the caller's UA.  For example, if the user has a combiled
cellular/WiFi phone, depending on the connectivity mode, the available
bandwidth to the phone may differ by a factor of 100.  Indeed, even
when using WiFi the bandwidth may vary, with a low rate when using a
commercial "hotspot" and a higher rate when using the free Wifi in the
office.  This can probably be integrated into the QoS and bandwidth
reservation needed for any truly demanding media stream.  But it may
be desirable to standardize how an OSIP accesses this information (for
the series of links which connect it to the caller).

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