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

From: "Bob Natale" <[email-masked]>
Date: Thu, 16 Mar 2006 10:59:32 -0500

"To my mind, if there are two incompatible implementations of
push-to-talk,
then (of necessity), one is not standard-compliant,"
                     ^^^^^^
s/b "one or both are" :)

Cheers,
BobN

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 10:53 AM
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

_______________________________________________
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: <[email-masked]>
Date: Fri, 24 Mar 2006 17:02:06 +0530

Stephen,

The following analogy does not seem to be appropriate.

> 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).

In this scenario you would neither need a different URI nor a service
identifier since the media types are different.

Regards,
Ravi.

> From: Stephen Terrill (E2/EEM) [mailto:[email-masked]] 
> Sent: Friday, March 24, 2006 2:40 PM
> To: Jonathan Rosenberg
> Cc: Rohan Mahy; sipping; Gonzalo Camarillo (JO/LMF); Dean Willis
> Subject: RE: [Sipping] Requirements for the identification of 
> 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
> 
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, March 22, 2006 4:53 PM
> Cc: sipping; Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
> 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>
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> -- 
> 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
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>