Re: [Sipping] I-D on service identification now available

[Dean Willis <dean.willis at softarmor.com>]

On May 9, 2007, at 3:12 AM, Juha Heinanen wrote:

> Markus.Isomaki at nokia.com writes:
>
> > Request-URI is totally opaque to the caller and caller's domain.  
> > Neither
> > of them can know without some further information, whether INVITE is
> > destined to IPTV session or a video conference.
>
> markus,
>
> how does caller's domain figure out from http uri what the service is?
> why this is a problem with sip and not http?  or if there is a  
> solution
> for http, why can't the same solution be applied to sip?

The phone company operators running the access networks want to have  
more control over your life with SIP than they currently have with HTTP.

For example, if you're using "Service=PORN", they want to be able to  
charge you extra, even though they're not really doing anything  
extra. Or perhaps they want to deny your usage of the service,  
because you haven't certified you're old enough. Note that with HTT,  
the service provider (not the access network provider) gets to make  
these choices. The access providers want to get in so they can get a  
bigger share of the "value".

The problem now is that every access-side operator would have to  
understand every possible service-side offering. The only way to do  
that is to reduce the set of potential services to a least-common  
denominator that is contractually agreed between the service  
providers. This is the death of service innovation in the Internet,  
and something I believe we must say "NO" to.

Further, it's why I think the SIP-level signaling should be opaque to  
the access network provider. It's none of their business, and the  
current protocol is flawed for having let them into the control channel.

--
Dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP