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

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

Hello Jonathan, All,

Thank-you for taking time to contribute with you knowledge.  I think
that the starting point from a 3GPP perspective is that there are what
you have termed "enumerated services", which andrew has explained, have
different characteristics and their own driving forces.  The Big three
are multimedia telephony, push-to-talk and messaging (a bit of a devide
and conqure to the problem space).  This does not preclude that a media
such as "voip" is present in more than one of these services (infact
voip is in at least Push-to-talk and multimedia telephony, and image and
text transfer could be in more than just messaging).  These are viewed
to be an aid to inter-operability, not a hinderance.  Without that, what
we have is a single massive communication services that does everything,
which implies that where network support is required, it is a single AS
that does everything; and a single client in the terminal that does
everything.

However - I do agree that such a concept can be abused, so I agree that
it should be used sparingly, otherwise we end up with the opposite
extreme which is many small communication services, which is equally
unmanageable.  

I don't believe in the URI per communication service approach (what a
step backwards that would be - we have that in cellular; one phone
number to contact me for telephony; onother to contact me with data; and
a third to contact me with fax).  It also has the disadvantage that it
doesn't seem to extend itself very well to "person - server"
communication (such as train timetable). 

I look forward to the continued discussions on this.

Best Regards,

..//steve

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Wednesday, March 22, 2006 4:53 PM
To: Stephen Terrill (E2/EEM)
Cc: sipping; Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
Subject: Re: [Sipping] Requirements for the identification of IMS
communication services.

Here are my thoughts on this topic.

Firstly, you are correct that there is a fairly extensive discussion on
this topic in terms of presence. I'd strongly suggest that folks take a
look at:

http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-mode
l-07.txt

and in particular, Section 3.3 on Services and Section 3.3.2, which
describes Reach Information. I'll quote three paragraphs that are
particularly relevant to this discussion:

>  It is difficult to give a precise definition for service.  One
>    reasonable approach is to model each software or hardware agent in
>    the system as a service.  If a user starts a softphone application
on
>    their PC, then that represents a service.  If a user has a
videophone
>    device, then that represents another service.  This is effectively
a
>    physical view of services.  This definition, however, starts to
fall
>    apart when a service is spread across multiple software agents or
>    devices.  For example, a SIP URI representing an address-of-record
>    can be routed to a softphone or a videophone, or both.  In that
case,
>    one might attempt instead to define a service based on its address
on
>    the network.  This definition also falls apart when modeling
devices
>    or applications that receive calls and dispatch them to different
>    "helpers" based on potentially complex logic.  For example, a
>    cellular telephone might house multiple SIP applications, each of
>    which can "register" different handlers based on the method or even
>    body type of the request.  Each of those applications or handlers
can
>    rightfully be considered a service, but it doesn't have an address
on
>    the network distinct from the others.
> 
>    Because of this inherent difficulty in precisely defining a
service,
>    the data model doesn't try to constrain what can be considered a
>    service.  Rather, anything can be considered a service so long as
it
>    exhibits a set of key properties defined by this model.  In
>    particular, Each service is associated with characteristics which
>    identify the nature and capabilities of that service, with reach
>    information that indicates how to connect to the service, with
status
>    information representing the state of that service, and relative
>    information that describes the ways in which that service relates
to
>    others associated with the presentity.
> 
>    As a consequence, in this model, services are not explicitly
>    enumerated.  There is no central registry where one finds
identifiers
>    for each service.  Consequently, each service does not have a
single
>    "service" attribute with values such as "ptt" or "telephony".  That
>    doesnt mean that these consolidated monikers aren't useful; indeed,
>    they represent an essential summary of what the service is.  Such
>    summarization is useful in creating icons that allow a user to
choose
>    one service over another. 

Regardless of whether you use presence or not, the discussion and
guidance here are directly applicable to this topic.

They key takeaway is that there are many dangers to interoperability
associated with the explicit enumeration of services; they require
global definition and agreement, and they result in (when taken to the
extreme), a separation of SIP communications into multiple parallel,
non-interoperable SIP networks, one for each vendor or service providers
definition of what the service is. I believe others have commented on
this within this thread. Nothing would be a greater crime to global
interoperability for 3gpp to define a service called 'voip' and then
require that only calls tagged with this service be processed and routed
to the 'voip' client on each phone. This would inhibit the ability of
clients outside of 3gpp to ever communicate with 3gpp endpoints, and
that is something I am sure we all want to avoid.

That said, the text above recognizes that there are cases where you need
to reach a specific instance of software in an endpoint because the
communications is in the context of that application, and is truly
meangingless outside of it. One example is voice communications that are
part of a multiplayer game, where the voice is in concert with non-sip
protocols that facilitate the game. In such a case, when I start a game,
and try and connect with another user, unless that user is also running
the game software, the voice communications should not take place. It
would be non-sensical to connect to, for example, a regular telephone or
voice-capable softphone that lacks the game.

The presence data model recognizes this, but strongly recommends that
the URI itself be distinct for each of these. Distinct URI are readily
obtained through presence. Each presence document would have a number of
'tuples', each of which identifies a unique service. Each unique service
has a unique service URI, which represents the mechanism I use to
contact someone for that service. In the case of the game, the ideal
solution is that I, in invoking this game, would subscribe to the
presence of sip:[email-masked], get back their presence, find the one
matching the game I'm interested in, and the select that URI. All of
that can happen automatically.

The data model further states that there are cases where the URI cannot
be used as a unique identifier for services, and indeed it calls out the
use case of a cellular phone, which is the exact case I believe you are
worried about. In that case, it recommends tecnologies like caller prefs
for this purpose. However, I will restate an important sentence in the
above:

>  Since the reach
>    information has to be understood in order for the service to be
>    utilized, reach information beyond the URI should be defined and
used
>    sparingly. 

With an emphasis on SPARINGLY.

Your text below has me quite worried that these guidelines are not being
adequately followed, and that will result in substantial
interoperability problems.

Thanks,
Jonathan R.

Stephen Terrill (E2/EEM) wrote:

> Hello All,
> 
> I am of the understanding that there have been some questions 
> regarding the requirements for the identification of IMS services.  I 
> would like to provide an understanding of the 3GPP discussions on this

> topic.  As I see it, the need to identify the IMS communication 
> services stems from that we have/are devloping different services on 
> IMS as a SIP infrastructure, such as push-to-talk over cellular (PoC)
or messaging.
> As there are different services and as it is not safe to rely on the 
> expressed media as the media may be used in different services then 
> there is the need to identify the service that is requisted.  This 
> could be seen as a means to identify the context upon which to 
> interpret the SIP signalling.  This is required to e.g. Identify the 
> application server that supports this communication service and to 
> identify the client to invoke in the terminating network.  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.
> 
> Please note that this is not intended to identify service that are 
> routed to, such as train time tables etc.  For these services, the 
> communication services is a means to route to and reach the ultimtate 
> end-user service.  This discussion is about how to identify the 
> communication service.
> 
> This has been discussed at an architectural level within 3GPP and a 
> Technical Report has been produced.  The Technical report can be found

> at _http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip_.  This 
> has been moved to approved status this week.  The essence of this 
> technical report has been included in specification text which can be 
> captured in 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060
> 468.ZIP_
> and
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060
> 469.ZIP_ .  Note that the changes included in S2-060468.ZIP are 
> changes to what was already included in the specification text last 
> year.  These documents represent the approved requirements within 
> 3GPP.
> 
> I can appreciate that a number of readers prefer to read this in text 
> instead of word, as such the approved 3GPP text that has been included

> in the specifications is included below.  As such, the text below are 
> the 3GPP stage 2 representation of the requirements.  It is worth 
> keeping in mind that the text below represensts archtectural 
> requirements and not the protocol realisation of these requirements.
> 
> Please don't hesitate to contact me if you have any questions.
> 
> I apologies in advance to the references to the 3GPP interfaces, they 
> are retained as I though it was better to avoid modifying any of the 
> agreed text when copying it into this email.
> 
> Best Regards,
> 
> Stephen Terrill
> 
> <Specification Text>
> 4.13.2  Identification of IMS communication Services A communication 
> service identifier provides a framework for the identification of IMS 
> communication services utilising the IMS enablers.  An IMS 
> communication service is provided via the use of the IMS enablers. At 
> terminals, the use of a communication service identifier is similar to

> the use of the port concept in TCP/IP, in that it allows applications 
> in a terminal and the network that use SIP for communication purposes 
> to be identified. In the terminal this means dispatching a SIP message

> to the correct application, and in the network it means selection of 
> the correct application server over ISC. Examples of IMS based 
> applications and communication services are OMA messaging and OMA PoC.
> 
> The communication service is an aggregation of one or several media 
> components and the service logic managing the aggregation, represented

> in the protocols used. Its behaviour and characteristics may be 
> standardized as done for the two examples above, or proprietary and 
> specific for e.g. an operator or an enterprise.
> 
> A service description specifies this behaviour and states e.g. the 
> allowed media combinations and state transitions as a consequence of 
> signalling and use of IMS enablers in the network and terminals.
> 
> The need of applying a service identifier is to be taken within the 
> specification of each individual service.
> The communication service identifier identifies IMS communication 
> services and shall be included in the relevant SIP methods.
> 
> The IMS communication service identifier shall fulfil the following
> requirements:
> 1. It shall be possible for the UE and an Application Server (AS) to 
> set the
>    IMS communication service identifier in a SIP request, e.g. in the
>    REGISTER and INVITE request.
> 2. Based on operator policy the S-CSCF or an AS shall be able to 
> validate an
>    IMS communication service identifier in a SIP request. This 
> includes e.g.
>    to check the syntactical correctness of a service identifier, and 
> policing
>    the usage of a communication service identifier.
> 3. It shall be possible, e.g. for the UE, S-CSCF and AS, to identify
an
>    IMS service uniquely by the IMS communication service identifier.
> 4. It shall be possible for the S-CSCF to invoke appropriate service
>    logic based on the IMS communication service identifier contained
>    in a SIP request, e.g. route a SIP request containing a service 
> identifier
>    based on initial filter criteria to the correct AS.
> 5. It shall be possible for the UE to invoke appropriate application
>    based on the IMS communication service identifier contained in a
>    received SIP request.
> 6. It shall be possible for the UE to indicate its service
capabilities
>    to the network, e.g. during registration, using the
>    IMS communication service identifier.
> 7. The structure of the IMS communication service identifier shall be
as
>    simple as possible, i.e. the IMS communication service identifier
shall
>    be limited to identify a service.
> 8. Based on operator policy S-CSCF and AS shall consider the
>    IMS communication service identifier for online and offline
charging,
>    e.g. put appropriate data into call detailed records.
> 9. The communication service identifier shall be capable of being an
>    input into the policy control and charging rules.
> 10. It shall be possible to use the IMS communication service
identifier as
>     a means to authorise whether a subscriber is allowed to initiate
or
>     receive request for a communication service.
> 11. The communication service identifier shall be taken into account
>     when selecting the correct UE(s), if multiple UEs are registered
>     for the same Public User Identity(s).
> 12. The usage of communication service identifiers shall not adversely
>     affect interoperability between IMS networks and interoperability
>     with external SIP networks and CS networks. The behaviour of a
network
>     receiving the IMS requests without an IMS communication service
>     identifier is a matter of operator policy. Usage of communication
>     service identifiers shall not decrease the level of
interoperability
>     with networks and UEs that are unaware of the communication 
> service identifier.
> 13. It shall be possible for the IMS network and UE to support 
> communications
>     that do not use a communication service identifier. In the case
that an
>     IMS communication service identifier is not present then the 
> network may
>     assume a particular IMS communication service.
> 14. The usage of communication service identifiers shall not restrict 
> the inherent
>     capabilities of SIP.
> 15. The usage of communication service identifiers shall not require 
> additional user
>     interaction, i .e. the communication service identifier is assumed
>     to be "added" by the UE that initiates the communication.
> 
> The network and the terminal shall be able to continue operation as 
> defined in 3GPP Release 5 and 3GPP Release 6.
> 
> The communication service identifier shall be available at least in 
> the following interfaces:
> -       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr;
> -       Cx; Dx (e.g as part of the iFC);
> -       Rx;
> -       Rf, Ro.
> 
> NOTE:   The communication service identifier does not replace the
> public service identity (PSI). The communication service identifier 
> would be used to indicate the communication service used to access the

> service addressed via a PSI, and is required to identify the 
> communication service even when SIP requests are sent towards another 
> entity without using a PSI.
> 
> 4.13.2  Identification of IMS applications
> 
> An IMS application is an application that uses an IMS communication
> service(s) in order to provide a specific service to the end-user.  
> The IMS application uses specific IMS Communication Service(s) and 
> provides the end user service through the reuse of the SIP 
> communication part of service. The IMS application does not extend the

> definition of the IMS communication service.  The IMS application 
> reference identifies the application utilising the IMS communication
service.
> 
> << removed figure >>
> 
> Figure 4.13-1:  IMS applications on top of an IMS communication 
> service The IMS application reference is used to identify the IMS 
> applications other than the default for the IMS communication service.

> The IMS application reference has significance at the UE and the SIP 
> AS behaving as SIP endpoints.  The means to transport the IMS 
> application reference is defined within the IMS communication 
> services.  When used, it shall be possible to transport the IMS 
> application reference on at least on the following interfaces:
> 
> *       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf
> 
> 
> </Specification Text>
> 
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> 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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Fri, 24 Mar 2006 09:05:57 -0500

On Fri, 2006-03-24 at 10:10 +0100, Stephen Terrill (E2/EEM) wrote:
> Without that, what

That describes the Internet, and you say that as if it is a bad thing.

And in regard to "network support": other than sending IP packets to
their destinations, what "network support" is needed?

I recall the days before the Internet, when each sort of data stream was
sent over its own communication facility.  It was taken for granted that
every data stream needed network support tailored to its particular
nature.  But the Internet has proven that is not so -- one simple
network infrastructure suffices to implement almost any data stream, and
the network need not pay attention to the nature of any data stream.

IMHO, the IMS architecture seeks to maintain the pre-unification
architecture of the current cell phone system, when instead it should
focus on efficiently carrying packets to and from mobile devices.  The
device users and manufacturers will create devices that use those
packets to do what users want.

Dale