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

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 29 Jun 2006 08:51:07 +0200

G'day Dale, All,

I guess that sometimes clarity is in the eye of the beholder (in the
same way as beauty).  Of course any comments to help with clarifying the
requirements is appreciated.

Regarding the *Purpose* of the requirements, I think that both of what
you have stated below are really intended, I have trouble to
differentiate between the two descriptions that you have layed out for
the CSIDs, and I also see that there are only going to be a small number
of them.

One thing to consider here is also that this is a means to "divide and
conquer" from the perspective of applications running on the SIP
infrastructure.  It doesn't seem like a feasable approach to force that
within the network and the terminals, there is one machine with a big
bunch of code that does "everything", but instead there is the need to
be able to divide the work up into seperate servers in the network, and
even seperate applications in the terminal.  In such a case, there is a
need to tag what the communication is for.

Regards,

Steve.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 5:48 PM
To: [email-masked]
Subject: Re: [Sipping] Requirements for the identification of
IMScommunicationservices.

I've skimmed draft-loreto-sipping-3gpp-ics-requirements-00.txt, and I
must say I'm totally at sea.  This wouldn't be significant, but it
suggests that as a set of requirements, it is only useful for someone
who already understands the subject, which isn't usually considered a
virtue for requirements.

First off, what is the *purpose* of these requirements?  If they're
actually just the requirements for the "Communications Service
Identifiers", the whole document seems like enormous overkill -- there
are going to be only a small number of communications service
identifiers, and they will be rigorously standardized.  In that case,
you could use small integers, or single words, or even ASCII punctuation
marks.  But that's a nearly arbitrary decision, and it makes little
difference.  There's no reason to use a heavy-weight decision mechanism.

I suspect what is really intended -- but is never stated directly -- is
to establish the entire *infrastructure* of tagging SIP communications
with communication service identifiers, laying out the logical sense of
CSIs, noting where and how they need to be specified in SIP messages,
etc.  But I don't see that stated in plain words anywhere.

It seems that there is some sort of implied structure of the whole
system, which is needed as a framework to make these requirements
comprehensible.  But again, this seems to be buried implicitly in
various definitions and requirements, rather than being stated in plain
words in an overview in front:  "Within IMS, an incoming request will be
routed to an S-CSCF, which will examine the communication service
identifier, and based on that, route it to an Application Server that
can handle the specified communication service..."  This is particularly
important as this is an entirely different structure than is envisioned
in any other SIP system.

Some points that probably need requirements are:

1) How do IMS SIP services interoperate with SIP services "on the
   greater Internet", which presumably do not use communication
   service identifiers?  (And what if an outside UA *does* use a
   communication service identifier?)

2) What considerations are needed to cope with the fact that two IMS
   SIP services are likely to implement slightly different versions of
   a communication service?

3) Can a UA or other SIP agent support more than one communication
   service?  The requirements seem to suggest that a single SIP
   request always involves only one communication service, but it
   seems plausible that some (REGISTER, especially) would want to
   express a set of communication services.

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

_______________________________________________
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: Thu, 29 Jun 2006 08:56:10 -0400

> the CSIDs, and I also see that there are only going to be a small number

I agree with Dale that the framework within which the CSID is intended 
to operate is far from clear, and the lack of it makes it difficult to 
have an informed discussion of the proposal.

I am at least passingly familiar with the IMS environment that this will 
be added to, and I still don't feel I have a good enough understanding 
of how this is intended to use. The people here who know even less about 
IMS must be having an even harder time.

So I second Dale and encourage an attempt to include a view of the 
overall framework for use of the CSID. And especially, a use-case or two 
with specific details of how it will be used. Then in drafts for 
specific proposals for the CSID the use cases can be elaborated using 
the proposed mechanisms.

> need to tag what the communication is for.

You will find that people here are all in favor of "divide and conquer". 
But what I am concerned about is *how* the division is being done, and 
who/what is being conquered.

The proposal seems to assume that the *same* division of function must 
be made in all participants in a call - caller, callee, caller's 
provider, callee's provider. That is very likely to constrain 
innovation, and lead to "stovepiping" that will impede open communication.

For instance, one implementation may consider PTT and two-way audio as 
entirely separate applications, that cannot coexist in the same call. 
Another application may consider them as simply "features" of a 
communication application, where switching back and forth mid-call 
between them (and IM too) is normal. One may require a server to support 
it, and the other may be able to do it all in the UA.

These ought to be able to coexist and interoperate. When both caller and 
callee are of the second type they should be able to switch freely among 
media. (When one of the participants is of the first type then perhaps 
that kind of switching may be impeded.)

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 29 Jun 2006 20:30:31 +0300

Hi,

as a chair, trying to facilitate discussions.

Below, Paul seems to be concerned about interoperability, and the fact 
that these identifiers may be "required" by some UACs. That is, if the 
terminating network or UA do not understand it, the call would not go 
thru even if both UAs were able to establish a session otherwise.

Further below, Salvatore states that these identifiers are informative 
in nature. That is, if the terminating network or UA understand it, the 
user experience will be somehow enhanced. However, if they do not 
understand it, the call will proceed as usual.

You may want to discuss this point further in order to clarify what is 
the intention with these identifiers: something that will be required 
and could keep systems from interoperate (something like an option tag 
in a Require header field) or something that would enhance somehow the 
user experience if it is supported but that will not break 
interoperability in any way if it is not (something like SDP attributes, 
which are simply ignored if they are not understood)?

Thanks,

Gonzalo

Salvatore wrote:

 > In our view Communication Identifier are just *informative*, with it we
 > want inform the UAS, that we would like to set a communication where the
 > media handling is not the standard one, for instance. Of course if the
 > UAS doesn't understand this tag, it can go on with the call using the
 > standard media handling.
 > Then how this *informative tag* is managed is a matter of the network,
 > the IMS network can use to route the signaling throw some specific proxy
 > or AS, where in a generic SIP network can be used to inform the UAS of
 > using a specific media logic