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

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Fri, 17 Mar 2006 18:50:10 +0100

Hello Dale, All,

Thanks for looking at this.  Regarding the reflection on the different
PoC, it was just a reflection from earlier discussion on push-to-talk
that there were different service definitions in different networks -
this could be due to being propriatory, or it could be due to different
standards organisations producing different service definitions, but
perhaps this is a side track.

I am unclear on why you feel that that having different service sets
"(in effect) splits SIP into a whole host of incompatible mini-SIPs,
each of which is supported by the mini-Internet of SIP devices that
participate in that "service"".  I would have thought that the aim would
be to have one global SIP network, providing global reachability, but
also allowing different services to utilise it. Without this, isn't is
such that we have one massive service which does lots of things.  The
concept of the communication service kind of allows us to break the
service space down into smaller problems which can be solved seperately.
The idea is that such a concept also provides a context for the
interpration of the signalling at the end points and at the points that
provide "routing" and "policy" in the event that special routing or
policy is required.

Best Regards,

Stephen Terrill

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 4:53 PM
To: Stephen Terrill (E2/EEM)
Cc: Sipping
Subject: Re: [Sipping] Requirements for the identification of
IMScommunication services.

On Thu, 2006-03-16 at 13:42 +0100, Stephen Terrill (E2/EEM) wrote

I'm having some difficulty understanding this essay.  I understand the
words, but I'm clearly not understanding the *philosophy* of what IMS is
attempting to do.

I think this passage is an example:

> While writting this, I seem to recall a parrallel discussion in 
> relation to presence, and that was along the lines that was that it 
> was required to identify the service that was used to communicate in 
> the presence, as otherwise two if the same presence information 
> appeared for two incompatabile services (e.g. two incomptable versions

> of push to talk) which fulfulled the same end-user expectation 
> appeared the same in presence, then the end-user would get confused as

> to why s/he could communicate with some users but not with others.

To my mind, if there are two incompatible implementations of push-to-
talk, then (of necessity), one is not standard-compliant, as all of the
SIP standards have been architected to provide interoperability.  And
when a device that supports some extension attempts to communicate with
a device that does not, a lot of thought has been put into making the
outcome be the best possible in the circumstance.

Whereas the 3GPP people seem to think of a set of "services", and any
communication must be tagged as which "service" it is using.  But this
(in effect) splits SIP into a whole host of incompatible mini-SIPs, each
of which is supported by the mini-Internet of SIP devices that
participate in that "service".

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: "Dale R. Worley" <[email-masked]>
Date: Mon, 20 Mar 2006 10:49:26 -0500

> provide "routing" and "policy" in the event that special routing or

It is difficult to explain, because it stems from a deep philosophical
question.  From the IETF point of view, "the network is dumb", and any
two endpoints can communicate in any way that they can both support.
(See Salzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System
Design", November 1984, for the classical statement of this philosophy.)

In this conception, there are no discrete "services". there is only
global reachability, and global interoperability limited *only* by the
capabilities of the endpoints.  In particular, once a packet leaves one
endpoint, it is carried by the network (but not "serviced by" or
"modified by" or "controlled by" or "has policy applied by" the network)
to the other endpoint.

There is indeed a global SIP network, and there are a whole host of
communication facilities which are "problems solved separately", but
those distinctions apply only to which capabilities are implemented in
which endpoint, *none* of them require that communications be
interpreted by the network, other than reading the "destination IP
address" in each packet.

Of course, SIP does not usually implement this philosophy in a pure
form, because of the need for registrar/proxies to make the last hop
routing to the individual telephone instrument.  But the proxy is still
envisioned to be controlled by the end user or the end user's
organization, not the network operator.

Dale