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

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Mon, 20 Mar 2006 19:27:48 +0100

Hello Ravi,
 
The text which seems to have caused confusion was trying to
differentiate between the "communication service" used to reach an end
user service; and the service that a user may be routing to.  Take the
ficticious example of a train time timetable service provided by a
certain operator.  The service may be reachable
SIP:[email-masked]; and I may use messaging,
push-to-talk, or multimedia telephony to reach it.  In this case, I
would call the "messaging", "push-to-talk" or "multimedia telephony" as
the communication services that such service identifiers are to
identify.
 
Is this clearer, or did the above just become more muddy?
 
Best Regards,
 
Stephen Terrill

________________________________

From: [email-masked]
[mailto:[email-masked]] 
Sent: Monday, March 20, 2006 1:33 PM
To: Stephen Terrill (E2/EEM); [email-masked]
Cc: [email-masked]; Gonzalo Camarillo (JO/LMF);
[email-masked]
Subject: RE: [Sipping] Requirements for the identification of IMS
communicationservices.

hi Stephen,
 
based on the requirements 3, 4, 5 I understand the need for this
identifier to be able to identify the service and the application to
handle it
at various nodes like the UE, S-CSCF, AS.
 
however, the following paragraph in your mail confuses me. can you
please explain further?
 
> 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.

thanks,
Ravi.

________________________________

From: Stephen Terrill (E2/EEM) [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 6:13 PM
To: sipping
Cc: Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
Subject: [Sipping] Requirements for the identification of IMS
communicationservices.

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
<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-060468
.ZIP
<http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-06046
8.ZIP>  and
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060469
.ZIP
<http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-06046
9.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> 

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

www.wipro.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: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 19:19:20 -0500

Stephen Terrill (E2/EEM) wrote:
> the communication services that such service identifiers are to identify.

In this example, exactly what is the difference between "messaging", 
"push-to-talk" and "multimedia telephony"? These sound simply like 
different media to me. So why would I do anything other than send an 
invite and offer the medium, or media, I want to use? And if later in 
the call I decide to use added media, I will be able to do so with a 
simple reinvite to add them.

In a somewhat less than ideal world, it might be that 
[email-masked] is actually implemented by 
three different UAs, one doing "messaging", one doing "push-to-talk" and 
one doing "multimedia telephony" (whatever that is). In such an 
unfortunate case somebody will have to choose one. If I only want to use 
one medium then this isn't a problem because there will be one server 
that does what I want. If I want to use multiple media then this will 
require a degree of compromise - which do I want more. This can be 
handled to some degree if those servers that don't handle my chosen 
media refuse my call. Its worse if there is some, but not complete, 
overlap between the capabilities of the different servers. This can be 
handled, within reason, by callerprefs.

In an even sadder world, there are intermediate notes (proxies, b2buas) 
between the caller and the callee that are required to be included in 
the call, but that each support one of these media. The tradeoffs are 
similar to above, but generally more severe. If there are overlaps in 
capabilities then again compromises need to be made. Callerprefs is not 
so clearly applicable in this case. It is designed to make a choice 
between a bunch of alternatives. It *might* be adapted to selecting 
among intermediate node servers, but its not clear how that would be 
achieved in an IMS environment.

> Is this clearer, or did the above just become more muddy?

Not sure.

	Paul

> Best Regards,
>  
> Stephen Terrill
> 
> ------------------------------------------------------------------------
> *From:* [email-masked] 
> *Sent:* Monday, March 20, 2006 1:33 PM
> *To:* Stephen Terrill (E2/EEM); [email-masked]
> *Cc:* [email-masked]; Gonzalo Camarillo (JO/LMF); 
> *Subject:* RE: [Sipping] Requirements for the identification of IMS 
> communicationservices.
> 
> hi Stephen,
>  
> ------------------------------------------------------------------------
> *From:* Stephen Terrill (E2/EEM) [mailto:[email-masked]]
> *Sent:* Thursday, March 16, 2006 6:13 PM
> *To:* sipping
> *Cc:* Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
> *Subject:* [Sipping] Requirements for the identification of IMS 
> communicationservices.
> 
> Hello All,
> 
> 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-060468.ZIP_ 
> and 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060469.ZIP_ 
> .  Note that the changes included in S2-060468.ZIP are changes to what 
> was already included in the specification text last year.  These 
> 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 
>    simple as possible, i.e. the IMS communication service identifier shall
> 10. It shall be possible to use the IMS communication service identifier as
>     with external SIP networks and CS networks. The behaviour of a network
>     that do not use a communication service identifier. In the case that an
>     to be “added” by the UE that initiates the communication.
> 
> •       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf
> 
> 
> </Specification Text>
> 
> 
> 
> ------------------------------------------------------------------------
>