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

Dale

Thanks so much again for taking the time to look at this. You've said a lot, and I want to 
give each of your points due consideration. I have addressed a few of them in line below, 
I'll have to think about the others a bit more.

-John

>* 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.
>

JH - This is good advice - thank you.

>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.

JH - IMS is one target. But it is not intended to be limited to IMS. 
The next revision will be clear about that, and probably will limit mention of
IMS specific details mainly as examples.

>
>* 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.
>

JH - yes. I've also been thinking that SPEERMINT might have some thoughts
about this, since a lot of what they deal with is driven by business 
relationships between providers. 

>* 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.)

JH - We thought a lot about this for cases where some VSP provides service
including something like a vanity name for an enterprise. Each "vanity domain" 
is just another SIP domain; it just happens to point to the actual provider's 
resources. Then each of these "vanity domains" needs to be specified to the OISP 
by the VSP that contracts with the OISP when that business arrrangement is set up. 

If VSP "A" provides service to the east coast office, and VSP "B" to the west coast 
office, it's not clear to me that the 2 offices could use the same vanity domain. 

I'd tend to agree that this could start to become unmanageable if we start seeing vanity domains
at the individual level.

>
>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.
>

JH - We thought about this, but thought it would be nearly impossible to
get something like a P-Header, so we opted to use something which already
exists. Right now we're mainly considering the subscriber's provider, and 
also allowing for the possibility that it could be a different provider that
has the relationship with the OISP. I've been pondering whether there's any basis for
needing the identity of some arbitrary provider along the way, when there are 
more than 2 levels of agreeements. This might be a question for SPEERMINT.

>* 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