Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 2 Mar 2007 14:18:55 -0800

Eric,

You are 100% correct, except these considerations don't apply for
services that are available for free, as is more and more the case for
VoIP and IM as well.

See for example the free voice services for the Iliad FTTH project to
wire Paris: http://www.iliad.fr/finances/2006/FREE_09-2006.pdf 

BTW: Has anyone seen a report on VoIP profitability by a service
provider?

If there is none, than VoIP may be worse than free for providers, VoIP
is a net loss as I suspect, but just not reported.

Now, how/why do you build innovative services that don't make money? :-)

Hint: Leave voice to the endpoints, such as Skype, SIP phones for free
SIP VoIP (there are quite a few such services).

My two cents, Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Sunday, February 25, 2007 9:11 PM
To: Byron Campen
Cc: [email-masked]
Subject: [Sipping] Billing Models, Protocols, and a Rant

I would offer that it is very much NOT our place to dictate pricing
models
on service providers or anyone else, for that matter.

For example, I am composing this message on an airplane.  I have a
polarizing security filter to reduce the ability of someone sitting next
to
me from reading my screen.  Why do I have such a filter?  Because once I
was
sitting next to a distributor for a very, very, very large, public,
networFrom [email-masked] Fri Mar 02 17:19:56 2007
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant
Date: Fri, 2 Mar 2007 14:18:55 -0800
From: "Henry Sinnreich" <[email-masked]>
To: "Eric Burger" <[email-masked]>, "Byron Campen" <[email-masked]>
Cc: [email-masked]

Eric,

You are 100% correct, except these considerations don't apply for
services that are available for free, as is more and more the case for
VoIP and IM as well.

See for example the free voice services for the Iliad FTTH project to
wire Paris: http://www.iliad.fr/finances/2006/FREE_09-2006.pdf 

BTW: Has anyone seen a report on VoIP profitability by a service
provider?

If there is none, than VoIP may be worse than free for providers, VoIP
is a net loss as I suspect, but just not reported.

Now, how/why do you build innovative services that don't make money? :-)

Hint: Leave voice to the endpoints, such as Skype, SIP phones for free
SIP VoIP (there are quite a few such services).

My two cents, Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Sunday, February 25, 2007 9:11 PM
To: Byron Campen
Cc: [email-masked]
Subject: [Sipping] Billing Models, Protocols, and a Rant

I would offer that it is very much NOT our place to dictate pricing
models
on service providers or anyone else, for that matter.

For example, I am composing this message on an airplane.  I have a
polarizing security filter to reduce the ability of someone sitting next
to
me from reading my screen.  Why do I have such a filter?  Because once I
was
sitting next to a distributor for a very, very, very large, public,
network
equipment company.  He happened to be reviewing that company's sales
forecast for the Eastern region, including sales prospects.  At first, I
thought, "Wow - that's cool!  If I were so inclined, I could mine his
prospects."  Then I realized, if I can read his super-secret stuff, he
could
read mine.

That's when I went out and bought the filter.

What is the point of the story?  I would be surprised if the filter
costs
more than USD 3 to manufacture.  Cost-based pricing would place the ASP
between $10 - $20 each.  However, they go for $50.  Why?  Because the
VALUE
of the product far outweighs what the cost-based price would indicate.

Same goes for telecommunication services.   Back in the day, I had a
platform that, from a single number, would find the subscriber, let the
subscriber know *really* who called, and let the subscriber control
ultimate
call treatment (connect call, send to voice mail, offer a polite Get
Lost,
etc.).  If you called the offering a single-number service, you could
hope
to charge $25/month + $0.50/min.  However, if you organized it to be a
personal assistant, given that you were replacing a (in those days)
$35,000/year assistant, you could easily charge a flat $1,000/month.
I'm
happy, because I'm making way better than 65% gross margin.  Subscriber
is
happy, because they are saving 60% of their costs, and getting a better
service.

If I were only allowed to create business models on cost, the world
would be
worse off.

THAT SAID, part of our special sauce was that we did NOT rely on the
telephone network for our billing.  Price is something entirely in the
service provider's control (barring governmental intervention, like
tariffs).  We could do our cool services BECAUSE we did not confuse
signaling with billing.

That has been the IETF lesson for at least 20 years.  Thus, I will push
back
when one group says, "we have to put in this feature into a session
protocol
for billing" -or- when another group says, "service providers must use
my
model for billing."

On 2/25/07 12:11 PM, "Byron Campen" <[email-masked]> wrote:

> This is more palatable than having the UAs provide these
> identifiers. I can still see interop problems down the road where UAs
> could confuse (or deliberately mislead) the S-CSCF by trying to do
> something with which it is not familiar. It seems to me that
> approaching this from the angle of "we have a fixed set of services,
> with individual pricing" is fundamentally and unavoidably at odds
> with the basic structure of SIP. Pricing should be based on the
> amount of work that the provider has to do. This is extremely easy to
> figure out. Bandwidth costs x, location service (ie, call
> establishment) costs y, other functionality (that your servers have
> to do work to accomplish) will cost whatever you feel is appropriate,
> etc. Putting in all the extra infrastructure/logic to simulate the
> charging for old 2G networks, or even the PSTN, seems pointless to
> me. You end up wasting money, time(ie, money), and effort(ie, more
> money). Why not use a charging system that isn't a total pain to
> implement? If you base your charging on the actual work you're doing,
> there is less to exploit in your system, and you can make _more_
> money because you don't have all the overhead from the PSTN billing
> emulation layer! Adopting this strategy does not impede your ability
> to set your pricing to any level you want. It in no way impedes your
> ability to make money.
> 
> Best regards,
> Byron Campen
> 
>> Paul's analysis is reasonable. Basically, starting with Andrew's
>> list, I see service identification as a business issue. To optimize
>> operation in the IMS architecture, it would seem reasonable in
>> several cases for the originating S-CSCF to identify the tariffed
>> service(s) implied by the messaging from the UA and add the
>> appropriate administrative header fields so downstream elements
>> don't have to repeat the analysis.
>> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>k
equipment company.  He happened to be reviewing that company's sales
forecast for the Eastern region, including sales prospects.  At first, I
thought, "Wow - that's cool!  If I were so inclined, I could mine his
prospects."  Then I realized, if I can read his super-secret stuff, he
could
read mine.

That's when I went out and bought the filter.

What is the point of the story?  I would be surprised if the filter
costs
more than USD 3 to manufacture.  Cost-based pricing would place the ASP
between $10 - $20 each.  However, they go for $50.  Why?  Because the
VALUE
of the product far outweighs what the cost-based price would indicate.

Same goes for telecommunication services.   Back in the day, I had a
platform that, from a single number, would find the subscriber, let the
subscriber know *really* who called, and let the subscriber control
ultimate
call treatment (connect call, send to voice mail, offer a polite Get
Lost,
etc.).  If you called the offering a single-number service, you could
hope
to charge $25/month + $0.50/min.  However, if you organized it to be a
personal assistant, given that you were replacing a (in those days)
$35,000/year assistant, you could easily charge a flat $1,000/month.
I'm
happy, because I'm making way better than 65% gross margin.  Subscriber
is
happy, because they are saving 60% of their costs, and getting a better
service.

If I were only allowed to create business models on cost, the world
would be
worse off.

THAT SAID, part of our special sauce was that we did NOT rely on the
telephone network for our billing.  Price is something entirely in the
service provider's control (barring governmental intervention, like
tariffs).  We could do our cool services BECAUSE we did not confuse
signaling with billing.

That has been the IETF lesson for at least 20 years.  Thus, I will push
back
when one group says, "we have to put in this feature into a session
protocol
for billing" -or- when another group says, "service providers must use
my
model for billing."

On 2/25/07 12:11 PM, "Byron Campen" <[email-masked]> wrote:

> This is more palatable than having the UAs provide these
> identifiers. I can still see interop problems down the road where UAs
> could confuse (or deliberately mislead) the S-CSCF by trying to do
> something with which it is not familiar. It seems to me that
> approaching this from the angle of "we have a fixed set of services,
> with individual pricing" is fundamentally and unavoidably at odds
> with the basic structure of SIP. Pricing should be based on the
> amount of work that the provider has to do. This is extremely easy to
> figure out. Bandwidth costs x, location service (ie, call
> establishment) costs y, other functionality (that your servers have
> to do work to accomplish) will cost whatever you feel is appropriate,
> etc. Putting in all the extra infrastructure/logic to simulate the
> charging for old 2G networks, or even the PSTN, seems pointless to
> me. You end up wasting money, time(ie, money), and effort(ie, more
> money). Why not use a charging system that isn't a total pain to
> implement? If you base your charging on the actual work you're doing,
> there is less to exploit in your system, and you can make _more_
> money because you don't have all the overhead from the PSTN billing
> emulation layer! Adopting this strategy does not impede your ability
> to set your pricing to any level you want. It in no way impedes your
> ability to make money.
> 
> Best regards,
> Byron Campen
> 
>> Paul's analysis is reasonable. Basically, starting with Andrew's
>> list, I see service identification as a business issue. To optimize
>> operation in the IMS architecture, it would seem reasonable in
>> several cases for the originating S-CSCF to identify the tariffed
>> service(s) implied by the messaging from the UA and add the
>> appropriate administrative header fields so downstream elements
>> don't have to repeat the analysis.
>> 
> 
> _______________________________________________
> 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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
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

_______________________________________________
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: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Sun, 4 Mar 2007 22:01:40 -0500

Henry,

VoIP in small (have they reached a billion yet?) closed communities may
work, but now scale that globally.  Saying you rely on PSTN to complete
calls outside that community shows it is not ready for prime time.
Security is still a major issue.  Voice is still a killer application.
We need to be able to pick up any phone in the world and phone home.

It is not really "free", they are just free-loading on the investments
of others.

Mike

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 5:19 PM
> To: Eric Burger; Byron Campen
> Cc: [email-masked]
> You are 100% correct, except these considerations don't apply 
> for services that are available for free, as is more and more 
> the case for VoIP and IM as well.
> 
> See for example the free voice services for the Iliad FTTH 
> project to wire Paris: 
> http://www.iliad.fr/finances/2006/FREE_09-2006.pdf 
> 
> BTW: Has anyone seen a report on VoIP profitability by a 
> service provider?
> 
> If there is none, than VoIP may be worse than free for 
> providers, VoIP is a net loss as I suspect, but just not reported.
> 
> Hint: Leave voice to the endpoints, such as Skype, SIP phones 
> for free SIP VoIP (there are quite a few such services).
> 
> My two cents, Henry
> 
> I would offer that it is very much NOT our place to dictate 
> pricing models on service providers or anyone else, for that matter.
> 
> For example, I am composing this message on an airplane.  I 
> have a polarizing security filter to reduce the ability of 
> someone sitting next to me from reading my screen.  Why do I 
> have such a filter?  Because once I was sitting next to a 
> distributor for a very, very, very large, public, network 
> equipment company.  He happened to be reviewing that 
> company's sales forecast for the Eastern region, including 
> sales prospects.  At first, I thought, "Wow - that's cool!  
> If I were so inclined, I could mine his prospects."  Then I 
> realized, if I can read his super-secret stuff, he could read mine.
> 
> What is the point of the story?  I would be surprised if the 
> filter costs more than USD 3 to manufacture.  Cost-based 
> pricing would place the ASP between $10 - $20 each.  However, 
> they go for $50.  Why?  Because the VALUE of the product far 
> outweighs what the cost-based price would indicate.
> 
> platform that, from a single number, would find the 
> subscriber, let the subscriber know *really* who called, and 
> let the subscriber control ultimate call treatment (connect 
> call, send to voice mail, offer a polite Get Lost, etc.).  If 
> you called the offering a single-number service, you could 
> hope to charge $25/month + $0.50/min.  However, if you 
> organized it to be a personal assistant, given that you were 
> replacing a (in those days) $35,000/year assistant, you could 
> easily charge a flat $1,000/month.
> I'm
> happy, because I'm making way better than 65% gross margin.  
> Subscriber is happy, because they are saving 60% of their 
> costs, and getting a better service.
> 
> If I were only allowed to create business models on cost, the 
> world would be worse off.
> 
> THAT SAID, part of our special sauce was that we did NOT rely 
> on the telephone network for our billing.  Price is something 
> entirely in the service provider's control (barring 
> governmental intervention, like tariffs).  We could do our 
> cool services BECAUSE we did not confuse signaling with billing.
> 
> That has been the IETF lesson for at least 20 years.  Thus, I 
> will push back when one group says, "we have to put in this 
> feature into a session protocol for billing" -or- when 
> another group says, "service providers must use my model for billing."
> 
> 
> identifiers. 
> > I can still see interop problems down the road where UAs 
> could confuse 
> > (or deliberately mislead) the S-CSCF by trying to do something with 
> > which it is not familiar. It seems to me that approaching this from 
> > the angle of "we have a fixed set of services, with individual 
> > pricing" is fundamentally and unavoidably at odds with the basic 
> > structure of SIP. Pricing should be based on the amount of 
> work that 
> > the provider has to do. This is extremely easy to figure out. 
> > Bandwidth costs x, location service (ie, call
> > establishment) costs y, other functionality (that your 
> servers have to 
> > do work to accomplish) will cost whatever you feel is appropriate, 
> > charging for old 2G networks, or even the PSTN, seems 
> pointless to me. 
> > You end up wasting money, time(ie, money), and effort(ie, 
> more money). 
> > Why not use a charging system that isn't a total pain to 
> implement? If 
> > you base your charging on the actual work you're doing, 
> there is less 
> > to exploit in your system, and you can make _more_ money 
> because you 
> > don't have all the overhead from the PSTN billing emulation layer! 
> > Adopting this strategy does not impede your ability to set your 
> > pricing to any level you want. It in no way impedes your ability to 
> > make money.
> > 
> > Best regards,
> > Byron Campen
> > 
> >> appropriate administrative header fields so downstream 
> elements don't 
> >> have to repeat the analysis.
> >> 
> > 
> > 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
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Byron Campen <[email-masked]>
Date: Mon, 5 Mar 2007 10:51:14 -0600

To be fair, the reason these closed communities rely on the PSTN is  
not because these communities lack infrastructure. They have all the  
infrastructure that is needed, in theory, from the internet. The  
reason these networks talk to the PSTN is because endpoints have not  
migrated over to their protocol (and for something as ubiquitous as  
phone service, this will take a LONG time). Mind you, the fact that  
we have the SIP/Skype division may cause traffic to be routed through  
the PSTN in order to connect the two networks, but there are already  
gateways out there that bridge the two protocols without relying on  
the PSTN. These communities avoid traversing the PSTN unless it  
absolutely cannot be avoided (because, after all, it is more  
expensive). And to imply that these services are "free-loading" off  
the PSTN seems wrong; someone is paying the phone companies for this  
access one way or another. Perhaps you feel they are not paying  
_enough_, but that is something the phone companies are responsible  
for sorting out.

	I will agree with you that these services are "not ready for prime  
time". There is still crucial standardization and implementation work  
to be done. (Standardization of emergency services, implementation of  
security, implementation of not-broken SIP, etc.) But, the maturity  
of implementations is steadily improving, and will eventually get to  
the point where anyone who wants a SIP soft-phone will be able to get  
one for free or a comparable price to that paid in their local  
WalMart for a PSTN phone. (hardware SIP phones will also be available  
for not too much money) And if interoperability isn't murdered (a  
higher risk than I am comfortable with, and the crux of this  
discussion) they will have any number of cheap (or if access to the  
PSTN isn't required, free) service providers to chose from that will  
allow them to talk to effectively anyone. This is the natural  
evolution of SIP.

Best regards,
Byron Campen

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 5 Mar 2007 21:09:52 -0500

Byron,

When folks say "free" they are thinking only of whether the end-user is
making a payment for the calls in some fashion.  But, these calls are
not carried from terminal to terminal over an "ether".  There are real
networks with real costs that have to be paid by someone somehow.  The
revenue from voice services on the PSTN paid for the creation of the
transmission and other facilities.  When you kill the goose that lays
the golden eggs, don't expect to have more eggs the next day.  At the
very least, a new business model is needed.  Just make sure there is
global connectivity and no SPIT.

Mike

> From: Byron Campen [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 11:51 AM
> To: Michael Hammer (mhammer)
> Cc: Henry Sinnreich; Eric Burger; [email-masked]
> Subject: Re: [Sipping] Billing Models, Protocols, and a Rant
> 
> 	To be fair, the reason these closed communities rely on 
> the PSTN is not because these communities lack 
> infrastructure. They have all the infrastructure that is 
> needed, in theory, from the internet. The reason these 
> networks talk to the PSTN is because endpoints have not 
> migrated over to their protocol (and for something as 
> ubiquitous as phone service, this will take a LONG time). 
> Mind you, the fact that we have the SIP/Skype division may 
> cause traffic to be routed through the PSTN in order to 
> connect the two networks, but there are already gateways out 
> there that bridge the two protocols without relying on the 
> PSTN. These communities avoid traversing the PSTN unless it 
> expensive). And to imply that these services are 
> "free-loading" off the PSTN seems wrong; someone is paying 
> the phone companies for this access one way or another. 
> Perhaps you feel they are not paying _enough_, but that is 
> something the phone companies are responsible for sorting out.
> 
> 	I will agree with you that these services are "not 
> ready for prime time". There is still crucial standardization 
> and implementation work to be done. (Standardization of 
> emergency services, implementation of security, 
> implementation of not-broken SIP, etc.) But, the maturity of 
> implementations is steadily improving, and will eventually 
> get to the point where anyone who wants a SIP soft-phone will 
> be able to get one for free or a comparable price to that 
> paid in their local WalMart for a PSTN phone. (hardware SIP 
> phones will also be available for not too much money) And if 
> interoperability isn't murdered (a higher risk than I am 
> comfortable with, and the crux of this
> discussion) they will have any number of cheap (or if access 
> to the PSTN isn't required, free) service providers to chose 
> from that will allow them to talk to effectively anyone. This 
> is the natural evolution of SIP.
> 
> Best regards,
> Byron Campen
> 
> 
> > Henry,
> >
> > VoIP in small (have they reached a billion yet?) closed communities 
> > may work, but now scale that globally.  Saying you rely on PSTN to 
> > complete calls outside that community shows it is not ready 
> for prime 
> > time.
> >> services that are available for free, as is more and more the case 
> >> for VoIP and IM as well.
> >>
> project to 
> >> wire Paris:
> >> If there is none, than VoIP may be worse than free for providers, 
> >> VoIP is a net loss as I suspect, but just not reported.
> >>
> >> Now, how/why do you build innovative services that don't 
> make money? 
> >> :-)
> >>
> >> Hint: Leave voice to the endpoints, such as Skype, SIP phones for 
> >> free SIP VoIP (there are quite a few such services).
> >>
> >> My two cents, Henry
> >>
> >> models on service providers or anyone else, for that matter.
> >>
> >> polarizing security filter to reduce the ability of 
> someone sitting 
> >> next to me from reading my screen.  Why do I have such a filter?  
> >> Because once I was sitting next to a distributor for a very, very, 
> >> very large, public, network equipment company.  He happened to be 
> >> reviewing that company's sales forecast for the Eastern region, 
> >> including sales prospects.  At first, I thought, "Wow - 
> that's cool!
> >> If I were so inclined, I could mine his prospects."  Then 
> I realized, 
> >> if I can read his super-secret stuff, he could read mine.
> >>
> >> costs more than USD 3 to manufacture.  Cost-based pricing 
> would place 
> >> the ASP between $10 - $20 each.  However, they go for $50.  Why?  
> >> Because the VALUE of the product far outweighs what the cost-based 
> >> price would indicate.
> >>
> subscriber, let 
> >> the subscriber know *really* who called, and let the subscriber 
> >> control ultimate call treatment (connect call, send to voice mail, 
> >> offer a polite Get Lost, etc.).  If you called the offering a 
> >> single-number service, you could hope to charge $25/month + 
> >> $0.50/min.  However, if you organized it to be a personal 
> assistant, 
> >> given that you were replacing a (in those days) $35,000/year 
> >> assistant, you could easily charge a flat $1,000/month.
> >> I'm
> >> would be worse off.
> >> telephone network for our billing.  Price is something entirely in 
> >> the service provider's control (barring governmental intervention, 
> >> like tariffs).  We could do our cool services BECAUSE we did not 
> >> confuse signaling with billing.
> >>
> >> That has been the IETF lesson for at least 20 years.  Thus, I will 
> >> push back when one group says, "we have to put in this 
> feature into a 
> >> session protocol for billing" -or- when another group 
> says, "service 
> >> providers must use my model for billing."
> >>
> >>
> >>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> Notice:  This email message, together with any attachments, may 
> >> contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> >> affiliated entities,  that may be confidential,  proprietary,  
> >> copyrighted  and/or legally privileged, and is intended solely for 
> >> the use of the individual or entity named in this message. 
> If you are 
> >> not the intended recipient, and have received this message 
> in error, 
> >> please immediately return this by email and then delete it.
> >>
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 5 Mar 2007 18:19:16 -0800

Mike,

> VoIP in small (have they reached a billion yet?)
Compare Skype to any other, its 100:1

Free IP to IP calls is not freeloading on anybody.

I pay Internet access to Time Warner and Vonage+Skype (free video to see
grandson) to call everywhere, exactly as you say. Most of the people I
care about have these two services already.

> BTW: Has anyone seen a report on VoIP profitability by a 

Maybe all these SIP extensions stand in the way to not being able to
report profitability. Will more extensions (how do you stop them) change
it for the better?  :-)

Now getting serious: Is the ever increasing number of SIP extensions a
scalable model? 
How do you stop the competition to invent more and more extensions?

Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Sunday, March 04, 2007 9:02 PM
To: Henry Sinnreich; Eric Burger; Byron Campen
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Henry,

Mike

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 6 Mar 2007 04:28:52 +0200

> Now getting serious: Is the ever increasing number of SIP extensions a

definitely not.  it would be a good idea to make an inventory of all sip
related rfcs and obsolete all that haven't been widely implemented.  i
suspect that very few would be left standing.

-- juha

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 5 Mar 2007 22:58:54 -0500

Henry,

In a way, I am agreeing with you.  There is no free lunch here, you pay
for it one way or another.  Folks are just not seeing how they pay for
it.

Mike

> Sent: Monday, March 05, 2007 9:19 PM
> To: Michael Hammer (mhammer); Eric Burger; Byron Campen
> Cc: [email-masked]
> grandson) to call everywhere, exactly as you say. Most of the 
> people I care about have these two services already.
> 
> Maybe all these SIP extensions stand in the way to not being 
> able to report profitability. Will more extensions (how do 
> you stop them) change it for the better?  :-)
> 
> Now getting serious: Is the ever increasing number of SIP 
> extensions a scalable model? 
> VoIP in small (have they reached a billion yet?) closed 
> communities may work, but now scale that globally.  Saying 
> you rely on PSTN to complete calls outside that community 
> shows it is not ready for prime time.
> It is not really "free", they are just free-loading on the 
> investments of others.
> 
> Mike
> 
> 
> providers, VoIP 
> > polarizing security filter to reduce the ability of someone sitting 
> > including sales prospects.  At first, I thought, "Wow - that's cool!
> realized, 
> > platform that, from a single number, would find the subscriber, let 
> $0.50/min.  
> > However, if you organized it to be a personal assistant, given that 
> > you were replacing a (in those days) $35,000/year 
> assistant, you could 
> > session protocol for billing" -or- when another group says, 
> "service 
> > copyrighted  and/or legally privileged, and is intended 
> solely for the 
> > use of the individual or entity named in this message. If 
> you are not 
> > the intended recipient, and have received this message in error,

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 5 Mar 2007 23:07:03 -0600

Adding to Rant, BCP for SIPS will be a nice addition to that queue :-)
With this attitude, we will need BCP for S/MIME and numerous other
unused stuff.... 

Nothing better than self-destruction before we lead towards SIP
Engineering Task Force...

Thx
Samir

>From: Juha Heinanen [mailto:[email-masked]] 
>Sent: Monday, March 05, 2007 6:29 PM
>To: Henry Sinnreich
>Cc: [email-masked]; Michael Hammer (mhammer)
>extensions a  > scalable model? 
>
>definitely not.  it would be a good idea to make an inventory 
>of all sip related rfcs and obsolete all that haven't been 
>widely implemented.  i suspect that very few would be left standing.
>
>-- juha
>
>[email-masked] for questions on current sip

---

From: [email-masked]
Date: Tue, 6 Mar 2007 10:36:34 -0500

From: "Michael Hammer \(mhammer\)" <[email-masked]>

   When folks say "free" they are thinking only of whether the end-user is
   making a payment for the calls in some fashion.

Or more exactly, whether they are paying a per-use charge for
"telephone calls".

   But, these calls are not carried from terminal to terminal over an
   "ether".  There are real networks with real costs that have to be
   paid by someone somehow.  The revenue from voice services on the
   PSTN paid for the creation of the transmission and other
   facilities.  When you kill the goose that lays the golden eggs,
   don't expect to have more eggs the next day.

I don't see what the problem is.  Almost all of the Internet,
including Skype, SIP, the Web, and this e-mail discussion are carried
over data lines, most of them rented from telcos and cable companies,
all of whom are (at last report) making a profit.  (And given the
politics of telco regulation, I expect that high capacity data lines
are subsidizing POTS pretty much everywhere in the world.)  That SIP
will bankrupt the telcos seems as unlikely as the Web bankrupting the
telcos.

There *is* a change in the economic landscape, but it's more subtle.
SIP makes the telephone service market more competitive, and by its
architecture, the supporting equipment is cheaper to develop (and
hence, sell).  This will make being a telco or a telephone equipment
vendor less of a sinecure, they will have to be competitive, and no
doubt a few of them will be killed off by new entrants to the market.
But that's market economics, and the death of one competitor at the
hands of another does not mean that the customers cannot buy what they
want.  Indeed, the opposite is true -- It's the industries where no
company ever loses money where customers have to pay high prices,
customers get a good deal in industries where companies are cutting
each other's throats.

Dale

---

From: Byron Campen <[email-masked]>
Date: Tue, 6 Mar 2007 10:49:51 -0600

I am not advocating killing the goose. I am pointing out that the  
goose has chosen pebbles as its favored nourishment, and it should  
not be surprised when it discovers that these are not very nutritious.

	I was going to follow this with a long sort-of-rant, but Dale has  
already written something better.

Best regards,
Byron Campen

>> investments

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Mar 2007 21:31:26 -0500

Dale,

Don't get me wrong.  I am not against change, innovation, or
competitiveness working their magic on the market.  I agree that there
are heavy and light ways of doing voice and how that gets allocated
between the end-user terminal and the network.  We are now in an era of
experimentation to see how this shakes out.  And some will choose the
wrong path and suffer the consequences of the market.

But, I am also suggesting that the user-perceived allocation of value
and revenue versus what is currently being charged will also undergo
change.  In the future, the $40 data and $30 voice may evolve to $69
data and $1 dollar voice as the actual distribution of costs in the
network migrate to the newer technologies.

Voice will be almost free.  Good.  The network cost still needs to be
covered.  All that will have happened is that the control mechanisms
will have shifted between application and network layers.

Mike

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 10:37 AM
> To: [email-masked]
> including Skype, SIP, the Web, and this e-mail discussion are 
> carried over data lines, most of them rented from telcos and 
> cable companies, all of whom are (at last report) making a 
> profit.  (And given the politics of telco regulation, I 
> expect that high capacity data lines are subsidizing POTS 
> pretty much everywhere in the world.)  That SIP will bankrupt 
> the telcos seems as unlikely as the Web bankrupting the telcos.
> 
> SIP makes the telephone service market more competitive, and 
> by its architecture, the supporting equipment is cheaper to 
> develop (and hence, sell).  This will make being a telco or a 
> telephone equipment vendor less of a sinecure, they will have 
> to be competitive, and no doubt a few of them will be killed 
> off by new entrants to the market.
> But that's market economics, and the death of one competitor 
> at the hands of another does not mean that the customers 
> cannot buy what they want.  Indeed, the opposite is true -- 
> It's the industries where no company ever loses money where 
> customers have to pay high prices, customers get a good deal 
> in industries where companies are cutting each other's throats.
> 
> Dale
>

---

From: "Willekens, Marc" <[email-masked]>
Date: Wed, 7 Mar 2007 13:25:04 +0100

Hi Michael,

It seems that the word "free" always has different meanings. I
understand "free" in the internet context as being free to select any
type of service out of a bulk of offered services. This is good for the
competition of new services because in the "old" days, end-users were
bound to the services offered by their walled garden operator domain.
But freedom always has a price. You don't get freedom for nothing,
instead you always have to invest a lot of time and money into it both
for CAPEX and OPEX.
And its true that in one way or another, the different costs in using
networks and resources have to be considered. When you need a resource
storage in the network, you can buy or rent such a resource, i.e. buying
your own server or renting processing power, storage and bandwidth from
someone else.

It's something as taking a subscription to a newspaper. You pay a "flat
rate", and then you have the free choice to read what you want from the
daily offered information. The other model would have been to pay for
every separate article that you want to read.

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

---

From: [email-masked]
Date: Wed, 7 Mar 2007 10:22:32 -0500

I don't see a problem with that.

Well, there are some important details that are being glossed over
here.

One thing we've noticed is that a high-capacity data trunk line costs
less than the same bit-rate trunk line divided into voice channels.
So some of our customers have been replacing the TDM trunks between
the PBXs at their locations with data lines, and sending phone calls
between the PBXs using SIP, at great savings in costs.

Exactly why the same network infrastructure is being charged at
different rates is unclear to me, but given that the telcos are
willing to rent the data lines, the data price must be covering the
costs, and the voice price must include some extra profit.

So we can expect that the expansion of SIP will result in the wringing
out of extra profits of this nature.

Similarly, since SIP only requires bulk digital transport from the
service providers, it places network providers into sharper
competition than before, as it becomes easier to substitute one
service provider for another.  This will tend to sharpen competition
between the service providers and make them more cost-conscious.  This
has already happened to the long-haul carriers (see what happened to
AT&T), but local service, "last mile" networking, is still largely
non-competitive.  As a consequence, it is still an industry with
nearly guaranteed profits and heavy unionization.

But with SIP, the technological hurdle to entering the last-mile
market is lowered.  Hopefully, the introduction of metro-area wireless
data technologies will make the last-mile market truly competitive,
and users can enjoy a serious reduction of prices.

In regard to "covering the network cost", that is an incorrect way to
analyze the situation.  Service providers spend CAPEX and OPEX and
charge prices; it is a measure of success or failure of the business
whether CAPEX and OPEX are covered or not.  There is no law of nature
that requires the costs to be covered, and in any properly functioning
market, some fraction of businesses will fail to do so.

Consider for comparison the airline industry in the US.  Previous to
deregulation, their costs were covered.  But as a consequence of the
non-competitive environment, the cost of service was quite high, to
the point that the term "jet set" referred to the affluent who could
afford to fly.  After deregulation, many airlines went bankrupt, and
even today, airlines have a hard time making a profit.  But the price
and availability of air travel is better than it has ever been before,
to the great benefit of the public.

And that is the miracle of capitalism.

(Or to phrase it in a left-wing way, our goal is to dramatically
reduce the cost of telecommunication services for the masses.)

Dale

---

From: Byron Campen <[email-masked]>
Date: Wed, 7 Mar 2007 10:18:11 -0600

Ok, we're on the same page here. This is the direction I see  
successful providers going in. However, I am pretty sure we will see  
a period where providers act in concert to preserve the old business  
model, by closing networks off to anyone but the heavyweights. My aim  
is to help avoid this, if at all possible, by pointing out that  
changing the business model is ultimately going to be less painful  
for everyone involved.

Best regards,
Byron Campen

---

From: "Willekens, Marc" <[email-masked]>
Date: Wed, 7 Mar 2007 23:28:31 +0100

Thanks Henry for the comment. And yes, when the endpoint is part of the
p2p network, it also becomes a resource component of the network. But,
you still need to buy a server system, install it locally and maintain
it. This has a cost. The difference with the existing network servers
with the client/server paradigm where the client is owned by the
end-user and the servers are owned by the network operators, is a shift
of the CAPEX and OPEX towards the end-users.
When considering aspects such as a reliable p2p network and when trying
to make use of mass of scale, there still can be good business cases to
provide the p2p network components under responsibility of the service
providers. Different deployment models for a p2p network are possible,
each having certain advantages/disadvantages.
Br,
Marc.

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 22:41
To: Willekens, Marc; Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Marc,

>different costs in using networks and resources have to be considered.
>When you need a resource storage in the network, you can buy or rent
such >a resource, i.e. buying your own server or renting processing
power, >storage and bandwidth from someone else.

The "network resources" can also be the endpoints as in P2P SIP
networks.

You can subscribe to [email-masked] or just browse p2psip.org where
these issues are addressed in great detail.

Comment: Self organizing P2P is like automating the conventional
networks, with similar consequences as automation in other industries.

Thanks, Henry

-----Original Message-----
From: Willekens, Marc [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 6:25 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi Michael,

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Mar 2007 13:40:40 -0800

Marc,

Thanks, Henry

-----Original Message-----
From: Willekens, Marc [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 6:25 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi Michael,

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 8 Mar 2007 07:27:47 -0800

Marc,

> there still can be good business cases to provide the p2p network 
> components under responsibility of the service providers

Yes, exactly!

Service providers can gain a lot from P2P as has been argued in
countless papers and presentations. But moving away from the VoIP
network infrastructure and the associated IT systems is a big
disruption, 
similar but bigger than moving from TDM to VoIP.

The reason why p2p is a bigger disruption than VoIP is that p2p does not
allow replication of the TDM model over IP, as most present VoIP
networks are doing. IMS is even overdoing the ISDN model.

Still, if service providers want to avoid to continue losing money with
VoIP, p2p is the best option for them it seems. That's what P2P SIP is
all about for VoIP service providers.

Thanks, Henry

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 22:41
To: Willekens, Marc; Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Marc,

Thanks, Henry

-----Original Message-----
From: Willekens, Marc [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 6:25 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi Michael,

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 12:20:04 -0500

Henry,

Are you considering this as strictly a system that doesn't interconnect 
with the PSTN?

Like it or not, (and mostly I don't) things that make calls to the PSTN, 
or that receive calls from the PSTN using E.164 numbers, are going to be 
subject to some of the PSTN regulations. That has to be dealt with 
somehow. There are still a lot of pstn phones I want to call and receive 
calls from. But I surely don't want those regulations to be imposed 
blindly where they don't apply.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 8 Mar 2007 09:42:29 -0800

Paul,

Paul,

> Are you considering this as strictly a system that doesn't 
> interconnect with the PSTN?

No, how did you get this idea!

> There are still a lot of pstn phones I want to call and 
> receive calls from.

Yes, absolutely.

As the I-Ds of the P2P SIP WG show, there are peers that act as proxy
SIP servers to the DNS world and there are IP-PSTN VoIP gateways.

BTW: You are just kidding, right? :-)

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, March 08, 2007 11:20 AM
To: Henry Sinnreich
Cc: Willekens, Marc; [email-masked]
Subject: Re: [Sipping] Billing Models, Protocols, and a Rant

Henry,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2007 15:42:52 -0500

> No, how did you get this idea!

Just wasn't sure. I haven't been paying close attention.

> BTW: You are just kidding, right? :-)

No. Sorry. But you didn't respond to the observation that these were 

> blindly where they don't apply.

Has this been investigated?

	Paul

---

From: vikram v <[email-masked]>
Date: Thu, 8 Mar 2007 15:30:32 -0800 (PST)

Hi 

I was wondering in P2P systems would there be a case for overload at all? Specially on the SIP UAs which assume the SIP server responsibility?

Regards
vikram

Henry Sinnreich <[email-masked]> wrote: Marc,

Yes, exactly!

Thanks, Henry

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 22:41
To: Willekens, Marc; Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Marc,

Thanks, Henry

-----Original Message-----
From: Willekens, Marc [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 6:25 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi Michael,

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

>    From: "Michael Hammer \(mhammer\)" 
> 

 
---------------------------------
Don't get soaked.  Take a quick peek at the forecast 
 with theYahoo! Search weather shortcut.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 8 Mar 2007 15:37:15 -0800

*       I was wondering in P2P systems would there be a case for
overload at all?

The interesting generic property of a well designed p2p network is the
more peers there are, the better it works.

Reports on possible congestion points, such a Skype supernodes say that
the traffic in the supernodes is amazingly small for both the signaling
and the media. See the measurements at:

http://iptps06.cs.ucsb.edu/papers/Guha-skype06.pdf 

http://saikat.guha.cc/pub/iptps06-skype/ 

Henry

________________________________

From: vikram v [mailto:[email-masked]] 
Sent: Thursday, March 08, 2007 5:31 PM
To: Henry Sinnreich; Willekens, Marc
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi 

I was wondering in P2P systems would there be a case for overload at
all? Specially on the SIP UAs which assume the SIP server
responsibility?

Regards
vikram

Henry Sinnreich <[email-masked]> wrote:

Marc,

Yes, exactly!

Thanks, Henry

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 22:41
To: Willekens, Marc; Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Marc,

Thanks, Henry

-----Original Message-----
From: Willekens, Marc [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 6:25 AM
To: Michael Hammer (mhammer)
Cc: [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Hi Michael,

Br,
Marc. 

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: woensdag 7 maart 2007 3:31
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Billing Models, Protocols, and a Rant

Dale,

Mike

 

________________________________

---

From: vikram v <[email-masked]>
Date: Fri, 9 Mar 2007 10:53:20 -0800 (PST)

Hi Folks

Please advise if there are any good papers indicating SIP overload scenarios and solutions thereof. 

Thanks
Henry Sinnreich <[email-masked]> wrote: Paul,

Paul,

Yes, absolutely.

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, March 08, 2007 11:20 AM
To: Henry Sinnreich
Cc: Willekens, Marc; [email-masked]
Subject: Re: [Sipping] Billing Models, Protocols, and a Rant

Henry,

 Paul

 
---------------------------------
 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 19 Mar 2007 13:42:36 -0400

Henry,

The problem is that the authentication/authorization is built into the
call signaling plane (IMS), and until a well-defined middle-layer policy
plane emerges to supercede that method of control, they will want to
rely on session setup signaling to provide that control.

Mike

> Sent: Thursday, March 08, 2007 10:28 AM
> To: Willekens, Marc
> Cc: [email-masked]
> Service providers can gain a lot from P2P as has been argued 
> in countless papers and presentations. But moving away from 
> the VoIP network infrastructure and the associated IT systems 
> is a big disruption, similar but bigger than moving from TDM to VoIP.
> 
> The reason why p2p is a bigger disruption than VoIP is that 
> p2p does not allow replication of the TDM model over IP, as 
> most present VoIP networks are doing. IMS is even overdoing 
> the ISDN model.
> 
> Still, if service providers want to avoid to continue losing 
> money with VoIP, p2p is the best option for them it seems. 
> That's what P2P SIP is all about for VoIP service providers.
> 
> Thanks, Henry
> 
> Thanks Henry for the comment. And yes, when the endpoint is 
> part of the p2p network, it also becomes a resource component 
> of the network. But, you still need to buy a server system, 
> install it locally and maintain it. This has a cost. The 
> difference with the existing network servers with the 
> client/server paradigm where the client is owned by the 
> end-user and the servers are owned by the network operators, 
> is a shift of the CAPEX and OPEX towards the end-users.
> When considering aspects such as a reliable p2p network and 
> when trying to make use of mass of scale, there still can be 
> good business cases to provide the p2p network components 
> under responsibility of the service providers. Different 
> deployment models for a p2p network are possible, each having 
> certain advantages/disadvantages.
> Br,
> Marc.
> 
> such >a resource, i.e. buying your own server or renting 
> processing power, >storage and bandwidth from someone else.
> 
> The "network resources" can also be the endpoints as in P2P 
> SIP networks.
> 
> You can subscribe to [email-masked] or just browse 
> p2psip.org where these issues are addressed in great detail.
> 
> Comment: Self organizing P2P is like automating the 
> conventional networks, with similar consequences as 
> automation in other industries.
> 
> Thanks, Henry
> 
> It seems that the word "free" always has different meanings. 
> I understand "free" in the internet context as being free to 
> select any type of service out of a bulk of offered services. 
> This is good for the competition of new services because in 
> the "old" days, end-users were bound to the services offered 
> by their walled garden operator domain.
> But freedom always has a price. You don't get freedom for 
> nothing, instead you always have to invest a lot of time and 
> money into it both for CAPEX and OPEX.
> And its true that in one way or another, the different costs 
> in using networks and resources have to be considered. When 
> you need a resource storage in the network, you can buy or 
> rent such a resource, i.e. buying your own server or renting 
> processing power, storage and bandwidth from someone else.
> 
> It's something as taking a subscription to a newspaper. You 
> pay a "flat rate", and then you have the free choice to read 
> what you want from the daily offered information. The other 
> model would have been to pay for every separate article that 
> you want to read.
> 
> Br,
> Marc. 
> 
> competitiveness working their magic on the market.  I agree 
> that there are heavy and light ways of doing voice and how 
> that gets allocated between the end-user terminal and the 
> network.  We are now in an era of experimentation to see how 
> this shakes out.  And some will choose the wrong path and 
> suffer the consequences of the market.
> 
> But, I am also suggesting that the user-perceived allocation 
> of value and revenue versus what is currently being charged 
> will also undergo change.  In the future, the $40 data and 
> $30 voice may evolve to $69 data and $1 dollar voice as the 
> actual distribution of costs in the network migrate to the 
> newer technologies.
> 
> Voice will be almost free.  Good.  The network cost still 
> needs to be covered.  All that will have happened is that the 
> control mechanisms will have shifted between application and 
> network layers.
> 
> Mike
> 
>