Subject: RE: [Sipping] Requirements fortheidentificationof IMScommunicationservices.

From: "Mark Searle" <[email-masked]>
Date: Sun, 26 Mar 2006 19:05:37 +0100

Hi All,

What ever the undoubted advantages of the Internet for delivery of data
services we have yet to see a functioning Internet voice service.  By
this I mean a commercial end-user replacement for the PSTN.  Even Skype
adds a caveat on its main page saying that its service is not a
replacement for the PSTN.  It is simply cherry picking technically
literate web users and offering a free service.  As a technically
literate user why wouldn't I take it under these conditions but would I
pay for it, no. When Skype goes wrong it can take quite some time and
technical know-how to fix the problem,  finding codecs, fixing firewalls
and removing interfering software.  

There were undoubted problems with the PSTN but I think the majority of
these are to do with it having a mature market for the services and less
because of technical reasons.  I look at the SIP message boards with
horror sometimes at the complexity that is creeping into the services
being developed.  This is even before we have proper working services.  

I am a big fan of integrating voice and Internet data services.  I think
SIP has a lot going for it but unless we really understand the legacy
and historical perspective of the PSTN and, yes, its advantages over IP
we are doomed to create another monster.

Regards Mark 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: 26 March 2006 16:17
To: 'Andrew Allen'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Requirements fortheidentificationof
IMScommunicationservices.

Andrew Allen wrote:

> What about Presence Servers, Resource List Servers, Conferencing
Servers,
> email servers, Transcoding Bridges, Media Gateways, voicemail servers,

> Message Relays, Message Stores, Location Servers, servers that protect
you
> from Spam and harasment (white lists and black lists), and Servers
that 
> support providing Consent for you to be added to a resource list?

All the above are indeed part of network based services and represent
the
telephone company view, mutated in the age of IP, after all telecom
networks
and their technology had to give way to the Internet. There are numerous
problems with the above approach, such as high costs, the inability to
innovate and lack of auditable security (mostly due to the huge
complexity).
In fact, none of the above are actually required for rich application
services but are pushed on the market for various revenue objectives,
that
may never be fulfilled for service providers.

The agenda of controlling the user from the network, besides being
repugnant, is also doomed to failure in the free market.

By contrast, the Internet view of the world is based on the e2e
principle,
because putting service in the network (such as mentioned above) stifles
innovation and removes user choice and control. Only the endpoints can
best
introduce, own and manage their own applications, state, data, etc.

These two views are reflected recently in the market by:

- The IMS, TISPAN, etc. network centric architectures, and the opposite
- Peer-to-peer applications whose traffic dominate the Internet.

Skype can be considered as a pre-standard P2P communication application
and
it dominates VoIP. SIP is also P2P by nature and servers are only
_optional_
, a fact that many tend forget.

The four meetings dedicated to P2P in general and P2P SIP at the 65 IETF
are
clearly an indication the Internet will recover from the network centric
approach pushed by the network based VoIP industry. See for more
information
http://www.p2psip.org/ietf.php and follow the postings from the 65 IETF.

So Dean Willis is right and please mark his words:

>>"network based service" is a misnomer, as we all know that the only 
>>network-based services are packet forwarding, routing topology 
>>management, and just possibly (but not usually in IP) admissions
control 
>>and congestion reporting.

Thanks, Henry

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Sunday, March 26, 2006 12:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Requirements for theidentificationof
IMScommunicationservices.

Dean

Dean Willis wrote:
"network based service" is a misnomer, as we all know that the only 
network-based services are packet forwarding, routing topology 
management, and just possibly (but not usually in IP) admissions control

and congestion reporting.

What about Presence Servers, Resource List Servers, Conferencing
Servers,
email servers, Transcoding Bridges, Media Gateways, voicemail servers,
Message Relays, Message Stores, Location Servers, servers that protect
you
from Spam and harasment (white lists and black lists), and Servers that
support providing Consent for you to be added to a resource list? 

It would also be difficult to see how Push to Talk Group calls would
work
with an acceptable user experience on constrained wireless networks
without
a server in the network that supports media burst control. Of course you
could always have one of the end user equipments perform the  media
burst
control - in fact the next release of OMA PoC will support such
functionality however this is really intended for human moderated push
to
talk sessions and other "special" push to talk applications and would be
too
slow for the regular Push to Talk experience.

The end to end model is fine and needs to be supported as does the end
to
middle model. Whether servers in the network are provided by the service
provider that provides connectivity or third parties is a commercial
issue
not a technology one.

I think taking the position that everything must be end to end is as
extreme
a position as the walled garden approach that everything must be end to
middle.

Where end to middle makes sense use that approach and where end to end
makes
sense use that approach. The technology should be provided that supports
either approach and ensures interoperability between a mix of these
approaches and then let the market decide which approach provides the
best
solution for each application.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: Dean Willis <[email-masked]>
To: Dale R. Worley <[email-masked]>
Cc: Sipping <[email-masked]>
Sent: Sat Mar 25 16:38:27 2006
Subject: Re: [Sipping] Requirements for the identificationof
IMScommunicationservices.

Dale R. Worley wrote:
> On Fri, 2006-03-24 at 12:51 -0600, Brian Stucker wrote:
> 
>>- A device has knowledge of certain (potentially, but not exclusively)
>>network based services that are available to it. How does it correctly
>>format it's request such that the set of services that it is
>>interested in having applied to the request are invoked in a generic
>>(standards-based) manner?
> 
> 
> Maybe I'm the only ignorant one here, but what is a "network based
> service"?
> 

Telco speak for "function invoked by a proxy or other service-provider 
equipment" rather than "function performed in an end-user network node."

The fact that we differentiate between "service provider equipment" and 
"end user equipment" and that this presumably says something about the 
function being perfromed speaks volumes about the design philosophy.

"network based service" is a misnomer, as we all know that the only 
network-based services are packet forwarding, routing topology 
management, and just possibly (but not usually in IP) admissions control

and congestion reporting.

--
Dean

_______________________________________________
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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public
information. Any use of this information by anyone other than the
intended
recipient is prohibited. If you have received this transmission in
error,
please immediately reply to the sender and delete this information from
your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be
unlawful.

_______________________________________________
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

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 26 Mar 2006 17:13:14 -0600

Mark Searle wrote:

> this I mean a commercial end-user replacement for the PSTN. 

So?

The Internet is NOT the PSTN. It is a different environment, with 
different principles, different physics, different goals, different 
business models, different applications, different regulation, and a 
different user experience.

Trying to exactly replicate the PSTN on top of the Internet is at best 
an academic exercise (and as Henning might say, I mean "academic in the 
worst way").

This is equivalent to using transgenetic science to turn a turkey-on-rye 
sandwich into a roast-beef-on-wheat:

http://www.sluggy.com/daily.php?date=060320

I've spent about ten years in this exercise and I've come to realize 
that while I believe using the Internet to provide applications that 
help people communicate is a very reasonable thing to do, there's no 
good reason to artificially constrain ourselves to trying to replace the 
PSTN, and that worrying about "Gee, we haven't replaced the PSTN yet" is 
a complete waste of time.

I expect that the PSTN will muddle along doing what it does, reliable, 
stable, and relatively stagnant, until it has become as relevant to the 
working world as the smoke signals of the neolithic plains dwellers are 
to today's average mobile-equipped high-school student. From time to 
time, there will be some transitional overlap requiring us to adapt, but 
that's not really the intent, focus, and mission of this working group.

To repphrase: The mission of the SIP working group is NOT to replicate 
and/or replace the PSTN. Our mission is to define an Internet protocol 
that facilitates human-centric real-time communications.

Given that OTHER organizations (generally outside of IETF) are trying to 
use our work to talk to (3GPP IMS), replicate (ETSI TISPAN ISDN 
supplementary services) or replace (ITU NGN) the PSTN or parts thereof, 
we SHOULD consider their requirements and MAY act upon them, but we MUST 
NOT jeopardize our mission in doing so.

This is the Internet. Behaving "like the PSTN" is just as much of a 
requirement to our work as "advancing 35mm film between two spools" is 
to digital photography. Get the picture?

--
Dean Willis

---

From: "Mark Searle" <[email-masked]>
Date: Mon, 27 Mar 2006 01:01:39 +0100

Hi,

There is a misunderstanding. I do not mean for you to replicate the act
of circuit switching at 64kbit per second.  That is easy.  You could do
it with wet string. My comment about skype was to do with running
communication services that are essential to the social and economic
well being of the country; that can be relied on in an emergency or when
the deal needs to be done.  With great responsibility comes great
dinosaur standards processes that are the curse of the PSTN as well as
one of its strengths.  Perhaps you believe that communication over the
internet should not aim for such lofty ideals.  Perhaps SIP should
therefore consider its position and inform the IMS standards body,
rather than politely consider its requirements, that SIP was never
intended to support resilient communications and the IMS is wasting its
time.  If you really believe this you might save them a lot of
unnecessary work.

Oh, and digital photography would never have taken over from 35mm if it
could not match the quality of 35mm and offer other benefits besides.
Can you say you have the correct metaphor yet?   

Regards Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 27 March 2006 00:13
To: Mark Searle
Cc: [email-masked]; 'Andrew Allen'; [email-masked];
[email-masked]
Subject: Mission focus (was Re: [Sipping] Requirements
fortheidentificationof IMScommunicationservices.)

So?

--
Dean Willis

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 26 Mar 2006 20:50:19 -0600

Mark,

You are raising an interesting point:

>Perhaps SIP should ...inform ...that 
>SIP was never intended to support resilient communications.

Here are some facts: During all major recent disasters, the Internet did not
fail while the telecom networks did fail. This has to do with the original
Internet design to withstand atomic warfare, design from the cold war years.

- During Katrina the mayor of New Orleans could reach the president only
using Vonage,
- During 7/11 in NY, only Internet communications worked, including an
emergency SIP service from Columbia University,
- During the floods in Central Europe, etc.

It is therefore high time to migrate the public emergency services and
emergency preemption services to the Internet. They will work more reliable,
at less cost and allow better communications, such as video and the
conveyance of location, vital signs, etc. And last but not least the
integration with emergency applications using SIP events and presence. 

Thanks, Henry

-----Original Message-----
From: Mark Searle [mailto:[email-masked]] 
Sent: Sunday, March 26, 2006 6:02 PM
To: 'Dean Willis'
Cc: [email-masked]; 'Andrew Allen'; [email-masked]; [email-masked]
Subject: RE: Mission focus (was Re: [Sipping] Requirements

Hi,

Regards Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 27 March 2006 00:13
To: Mark Searle
Cc: [email-masked]; 'Andrew Allen'; [email-masked];
[email-masked]

So?

--
Dean Willis

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 27 Mar 2006 07:51:37 +0300

Mark Searle writes:

 > Perhaps SIP should therefore consider its position and inform the IMS
 > standards body, 

who said that SIP cannot be used to support resilient communications?
the outbound i-d, for example, allows a phone to connect at the same
time to more than one "telephone exchange" in case one of them is
unavailable.  i haven't see that kind of possibility in PSTN.

the problem the we constantly have with IMS "requirements" is that they
try to implement walled gardens using SIP.  IETF should have simply said
"NO" to them long time ago.  the problem was, that in the early days
(and perhaps even now) some of the SIP fathers we working for companies
whose income at least partly relied on IMS and they didn't have guts to
tell IMS guys to go home from messing up and complicating SIP.

-- juha

---

From: "Mark Searle" <[email-masked]>
Date: Mon, 27 Mar 2006 09:13:05 +0100

Hi Juha,

I agree with you there.  There seem to be a mismatch between IMS and its
view of SIP and the IEFT's.  Clearly this has lead to overly complex
structures in the IMS. But, can you blame them? You implied yourself
that SIP has been somewhat subverted by companies with money and
resources.  This is the point.  It is commerce that drove the telco
sector into IP and IMS in the first place.  The internet has no doubt
benefited from this as it could not continue on state subsidies and top
slicing. Companies themselves are as much at the mercy of money as the
SIP fathers.  We all are.  We will unfortunately see a lot more of this
as legacy establishes itself.  This is also the history of the PTSN.
The technical solution has to make way for the realities of commerce and
government intervention. 

Yes, your are also correct that the IETF should stick to its guns more.
You guys understand your stuff more than anyone.  Perhaps you should be
the more of a counter weight to the commercial realities.  

Kind regards Mark.  

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 27 March 2006 05:52
To: Mark Searle
Cc: 'Dean Willis'; 'Andrew Allen'; [email-masked]
Subject: RE: Mission focus (was Re: [Sipping]
Requirementsfortheidentificationof IMScommunicationservices.)

-- juha

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 27 Mar 2006 07:07:49 -0600

Mark Searle wrote:

>There seem to be a mismatch between IMS and its view of SIP and the IEFT's.

Indeed. It is like comparing modern highways with medieval travel paths
between well guarded castles, protected by a moat and drawbridge and also
paying toll at every passage to support the local whimsical lords.

Sorry, I could not help it :-)

Thanks, Henry

-----Original Message-----
From: Mark Searle [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 2:13 AM
To: 'Juha Heinanen'
Cc: 'Andrew Allen'; [email-masked]; 'Dean Willis'
Subject: RE: Mission focus (was Re:
[Sipping]Requirementsfortheidentificationof IMScommunicationservices.)

Hi Juha,

Kind regards Mark.  

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 27 March 2006 05:52
To: Mark Searle
Cc: 'Dean Willis'; 'Andrew Allen'; [email-masked]
Subject: RE: Mission focus (was Re: [Sipping]

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 27 Mar 2006 10:21:23 -0500

(Why is the spacing of the Subject line getting damaged?)

> this I mean a commercial end-user replacement for the PSTN.

There's a whole swamp of questions here.

To pick a trivial one, I notice you say "a commercial end-user
replacement" not "an end-user replacement" above.  But all that the
public *needs* is a functional equivalent of the current PSTN, they do
not *need* to pay for it.  Though to make an equivalent, they will
likely to have to pay for it.  But that's not a requirement, that's an
implementation question.

A real example is e-mail servers.  Currently, I use four e-mail servers,
each one of which can receive messages directly.  One is owned and
operated by my employer, one is on my home computer, one is owned and
operated by my ISP, and one is a pure forwarder (no storage) operated by
my alma mater.  (Some of these incorporate anti-spam functionality as
well.)  In a way, they are all functionally equivalent.  From an IETF
point of view, they are all servers that use the network; from a PSTN
point of view, only one is "in the network".  Together they provide me
with various functionalities such that none of them are dispensable.  I
could also buy or otherwise arrange to receive e-mail on other servers,
some of which are operated by independent businesses.

Closer to home, consider voice mail.  I can purchase an answering
machine and attach it to my line.  I can also contract with the telco to
use one of their servers to perform a similar function, but co-located
with their switch, on the other end of my access line.  Given that my
access line is bandwidth-limited (can handle only one call at a time),
the telco service has significant advantages.  I could also contract
with an independent service and arrange for my calls to be routed to
their service.

In a real VoIP world, all services will have this flavor.  They will be
mixed-and-matched in various ways, and any given service will be
implementable in various ways, both technologically and economically.
The network providers will provide servers for some services, because
that's a parallel business, and they have low network-access cost, and
the staff to support a technological infrastructure.  But no service
will be inherently bound to the network service provider.

This will tend to cause a reduction in service reliability.  But I don't
know how much that theoretical tendency will be borne out in practice.
My telco-provided voicemail service doesn't seem to be much more
reliable than the consumer answering machine that it replaced.

Dale