Subject: RE: [Sipping] Requirements for the identification of IMScommunication services.

From: "Andrew Allen" <[email-masked]>
Date: Mon, 27 Mar 2006 10:53:40 -0500

Dale,

I think we are basically saying the same thing. In reality there will
likely be a mix of services provided end to end or by endpoints and
those provided by third parties including "in the network" by those who
also supply connectivity (at least initially). 

The challenge is to make sure that all these different paradigms
interoperate together. 

I don't think that taking a stubborn religious nethead vs bellhead
position either way on this is helpful in ensuring that interoperability
goal.

In 3GPP, TISPAN and OMA I seem to be viewed as some radical nethead and
in IETF as a bellhead so I guess in reality I am in the middle.

The market will ultimately decide which paradigm wins. 

The key question is does SIPPING want to work on this "Communication
Service Identifier" or not? If we don't then 3GPP will work on it anyway
and the solution will likely be one that we don't like that could
frustrate the goal of interoperability. This solution will then almost
certainly be re-used by 3GPP2, OMA, TISPAN, Cablelabs and any other
organisation reusing IMS.

Andrew

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 10:21 AM
To: Sipping
Subject: RE: [Sipping] Requirements for the identification of
IMScommunication services.

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

On Sun, 2006-03-26 at 19:05 +0100, Mark Searle wrote:
> 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.

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

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Mar 2006 12:02:19 -0500

Andrew,

I think there is definitely something here for ietf to work on. But I 
don't think it has been fully defined, or even that "it" is in reality 
one thing, or several.

I don't have a great conceptual problem with the need for some 
communication between a UA and servers of various sorts that may provide 
the UA will assistance on calls it originates, or that are destined for 
it. This kind of communication is in some sense a private matter - 
vocabulary for this can be dealt with via configuration and doesn't have 
huge interoperation issues.

Its more of a problem when a UAC wishes to request a service from a 
servoer operating on behalf of the target of a request the UAC is 
making. Interop problems can be severe here if callers and callees 
aren't part of a homogeneous community. So much more standardization is 
required.

Because of their differences, I think these two kinds of communication 
should probably be treated separately, rather than both being considered 
as aspects of the same "service identifier" problem. So perhaps we need 
"local service identifiers" and "remote service identifiers".

Also, I think we need to be very clear on whether a "service" is an 
attribute of a request or call, that potentially affects the behavior of 
any and all elements that process the request, or whether a service is 
something that is provided somewhere along the call path, so that an 
assortment of services might be applied to the request at various points 
along the path. (Not to imply that the requestor necessarily knows which 
point applies a service.)

As I have said repeatedly, I have difficulty accepting the concept of 
service as a distinguised way of classifying calls into mutually 
exclusive buckets.

	Paul