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

From: "Haluska, John J" <[email-masked]>
Date: Fri, 12 Jan 2007 01:37:53 -0500

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

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Mon, 15 Jan 2007 16:40:15 -0500

From: "Haluska, John J" <[email-masked]>

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

Permit me to suggest that you might consider information services that
are *not* driven by business relationships between providers, but are
freely chosen by the customers, outside the control of their
communication providers.

Indeed, let me make that statement stronger -- If you propose a
mechanism that constrains SIP users to only use information services
chosen and approved by their communication providers, and that
mechanism is somehow implemented, thousands of "net-heads" will work
night and day to subvert that control by the communication providers.

That is what is called "an open network".

The economic driver of Internet adoption is freeing users from the
control of their communication providers, and many people are very
passionate about that.  Do not attempt to standardize (though the
IETF!) an approach that the Internet community sees as necessary to
destroy.

Remember: VoIP was started by people who didn't want to pay the high
international voice charges between Israel and the US.

Dale

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 15 Jan 2007 14:13:12 -0800

>communication providers

100% correct.

I could only add: Models based on roaming charges such as the Visiting
Proxy are a rip-off for the users.

Such models have nothing to do with Internet usage which is mostly e2e
for the media (or using a media relay if there is no ICE) and two
proxies like in the trapezoid model in RFC 3261.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 3:40 PM
To: [email-masked]
Subject: Re: [Sipping] Some more thoughts
ondraft-haluska-sipping-directory-assistance-01.txt

Dale