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

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Tue, 21 Mar 2006 08:35:16 +0100

Hello Paul,

Perhaps the point here is that "messaging", "push-to-talk" and
"multimedia telephony" are all not soley different medias, though it
still could be possible that e.g. messaging media could exist under
multimedia telephony.  For example, push to talk has its own procedures
with it that describe its own means to transport the parties that are
being communicated with etc - abliet all using IETF techniques.
Multimedia telephony has its own procedures as well as I understand it.
Perhaps the difference of view is that from an IETF perspective, in
effect, there is one communication service with a number of medias
(though I am unsure of this); where-as in 3GPP there are a small number
of services; and there can be overlapping medias between the services.

Best Regards,

..//Steve

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, March 21, 2006 1:19 AM
To: Stephen Terrill (E2/EEM)
Cc: [email-masked]; [email-masked]; [email-masked];
Gonzalo Camarillo (JO/LMF); [email-masked]
Subject: Re: [Sipping] Requirements for the identification of IMS
communicationservices.

Stephen Terrill (E2/EEM) wrote:
> 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.

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] 
> [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_.  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>
> 
> 
> 
> 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

_______________________________________________
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: Tue, 21 Mar 2006 10:04:07 -0500

> of services; and there can be overlapping medias between the services.

Steve,

I have heard this enough that the words are familiar - that there is a 
different view here. But I for one still don't "get it". It almost seems 
to me that the there is a starting assumption that these are different 
services, and then the implementation is structured to validate the 
assumption, rather than there being an intrinsic difference that drives 
the distinction. I do understand that there are some technological 
issues that drive PoC to be *special* at the moment. I see those more as 
short term limitations than the basis for long term architectural 
direction. As another example, I know that traditionally there is a 
distinction between SMS and MMS. But AFAIK that is based on a 
technological limitation rather than an intrinsic distinction. So I 
would hope not to see "text messaging" and "multimedia messaging" as 
distinct "services".

What is supposed to happen when interoperating with users that don't 
have the same concept of how to partition capabilities into services?

	Paul