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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 23 Mar 2006 10:17:45 -0500

You say that technology should not be used to solve gouging problems.

The converse is also true, technology should not be used to create
gouging problems.

Mike

> -----Original Message-----
> From: Andrew Allen [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 7:28 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: sipping; Dean Willis; Stephen Terrill (E2/EEM); Gonzalo 
> Camarillo (JO/LMF); Rohan Mahy
> Subject: RE: [Sipping] Requirements for the identification 
> ofIMS communicationservices.
> 
> 
> Paul
> 
> Responses in line
> 
> Andrew
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, March 22, 2006 9:30 PM
> To: Andrew Allen
> Cc: Stephen Terrill (E2/EEM); sipping; Rohan Mahy; Gonzalo 
> Camarillo (JO/LMF); Dean Willis
> Subject: Re: [Sipping] Requirements for the identification of 
> IMS communicationservices.
> 
> Andrew,
> 
> Much commentary inline.
> 
> 	Paul
> 
> Andrew Allen wrote:
> > I have been a little delayed finding the time up to now to get into
> the 
> > public SIPPING list discussions on this. But I have already been 
> > involved earlier in some discussions on this within 3GPP and also 
> > privately with some of the SIPPING participants.
> >  
> > 
> > Firstly I am supportive of the basic requirement to provide a 
> > straightforward means to easily identify that SIP requests 
> are related
> 
> > to a particular communication service.
> > 
> > Of course it is possible to take a view that there is only a single 
> > communication service enabled by SIP however in reality I think both
> the 
> > average user and service providers have the need to group 
> and package 
> > features and capabilities together as "communication services"
> 
> I understand the desire to package groups of features 
> together for purposes of marketing, sales, billing, and 
> documentation. But I fail to see any reason why this has 
> anything to do with the implementation or signaling of those features.
> 
> There may also be reasons to package the server 
> implementation of multiple features into a single component, 
> for purposes of management ease, outsourcing, etc. This kind 
> of packaging ideally should be independent of the other kind 
> above, be invisible to the customer, and at best influence 
> signaling in a localized way, at the point(s) where the 
> server is interconnected with the larger system.
> 
> [AA] Yes - often the packaged services are also hosted on an 
> intermediate server that deals with interactions between 
> various features of the service and provides added value 
> features. Also charging is another aspect. In order to 
> provide service based charging there needs to be a capability 
> to easily identify that a SIP request is related to PoC as 
> opposed to telephony or messaging so that these services can 
> be charged separately. For example a user may get all his PoC 
> Calls included for a flat $20 a month, 600 Text Messages for 
> $5 a month and telephony calls charged at a per minute rate.
> 
> > 
> > My definition of a "communication service" is a somewhat arbitrary 
> > bundle or package of capabilities that make some sense when grouped 
> > together from either a user experience or a service 
> provider business 
> > perspective.
> 
> Lumping those two reasons together using a single mechanism 
> raises all sorts of red flags for me.
> 
> Things that are grouped together for purposes of user 
> experience are all
> 
> about the UI, which is usually controlled by the UE. There is 
> no particular reason it needs to go any further.
> 
> [AA] I agree that to a large degree this is a UI issue 
> however when standards bodies like OMA define an 
> Enabler/service this often results in an application based on 
> that enabler being included on the handset.
> This is especially visible if the application based on that 
> enabler is something downloaded to the client as a separate 
> application.
> 
> > Some service groupings are historical (such as replicating the 
> > telephony supplementary services of GSM or a 5ESS) others are
> based 
> > on a grouping of those capabilities available in popular products
> (such 
> > as MSN messenger and Netmeeting). Others may be "public 
> services" such
> 
> > as Emergency Services.
> 
> The implication here is that a user using voice services 
> can't make a call to a user using MSN messenger.
> 
> [AA] I think that "voice services" is a very broad category 
> and not the same as telephony. I think that telephony is 
> probably a service that to some extent emulates those 
> capabilities currently provided by current circuit switched 
> telephony systems such as 5ESS switches, GSM supplementary 
> services, ISDN voice services and those features provided by 
> the SS7 intelligent network. Voice services is more general 
> than that. Telephony services in the future may also be 
> multimedia and not just voice. I don't think IETF should 
> define these services just provide a mechanism for indication 
> of these service by the service defining organization.
>  
> I agree there can be multiple applications, each of which 
> packages an assortment of features, that applications will 
> have different combinations of features, and that in some 
> cases the same feature (e.g. 
> voice) may be supported by multiple applications.
> 
> But this doesn't mean that I need to name the application I 
> want you to use in order to call you. Rather it becomes an 
> optimization problem to choose the application with the 
> combination of features that best matches the combination of 
> features the caller wants to use. The caller can make the 
> choice directly via a suitable presence system, or indirectly 
> via caller preferences inserted by the caller's UA.
> 
> [AA] I agree that the use of the service identifier should 
> not be required to reach the user. I think this will only 
> create interoperability problems. This is one of the concerns 
> I have with the current feature tag in the Accept-Contact 
> header solution used by OMA and which some people in 3GPP 
> propose to extend as the general solution.
> 
> 
> I am inclined to think of these "applications" as UAs, each 
> independently registered. It needn't be that way - they can 
> be alternatives within a single UA in a single UE. While this 
> can be a viable way to build things it is likely to be 
> suboptimal for the user, because it artificially limits the 
> features that can be used together.
> 
> > If you try to provide users with several hundred 
> capabilities without 
> > some simple groupings that they can remember, understand 
> and relate to
> 
> > you end up with more options than they will buy or can practically
> use. 
> 
> To continue beating the dead horse, how you present these to 
> the user need have *nothing* to do with how you implement 
> network support for them.
> 
> > Therefore it is convenient and useful for users to have capabilities
> and 
> > features grouped or packaged together as "communication services". 
> > Remember that the average consumer cannot program their VCR!
> 
> Yes, but people who couldn't program their vcr can probably 
> operate a TiVo, which has vastly more features. That is all 
> about the quality of the UI design.
> 
> [AA] I don't think its just UI design. The fact is that most 
> people cannot keep track of a large number of concepts and it 
> is necessary to group them into categories so people can 
> understand them. An example is the grouping of the hundreds 
> of animal species into the groupings of Mammals, Reptiles, 
> Birds, Fish, and Insects or a Menu in a Chinese Restaurant 
> where the in excess of 100 dishes are grouped into Beef, 
> Seafood, Pork, Noodle.... categories on the menu. As a User I 
> need to have an easy way to understand how I will be charged 
> for using some capability. If the hundreds of capabilities 
> and their combinations and interactions are grouped together 
> into a simple set of services then I have a much better 
> understanding of how much I am likely to pay if I use various 
> capabilities than if every single capability is charged 
> separately even if they are presented to me with an easy to use UI.
> 
> >  From a service provider perspective packaging capabilities and
> features 
> > together as "communication services" allows them to sell different 
> > communication service options to their customers. I know 
> some take a 
> > view that "service based charging" is "evil" but I think it is 
> > unrealistic to expect that service providers will always 
> provide all 
> > services together for a flat fee especially when these services
> require 
> > investment in additional infrastructure such as Presence Servers, 
> > Conference Servers, Voice Mail Server, Media Servers, etc. 
> In fact it 
> > probably isn't in my interests as a user to have service providers 
> > provide everything all together for a flat fee because then 
> I will end
> 
> > up paying for all those things that I don't want or have 
> any use for.
> It 
> > is useful to give users some choice in what services they sign up to
> but 
> > in a way that reduces the total list of options to 
> something that is 
> > understandable to most people.
> 
> I agree that those who provide "services" need to be 
> reimbursed in some way in order to be incented to continue to 
> do so. But this is yet another aspect of this big picture, 
> that need not be coupled with the others.
> 
> In general this is most straightforward if you bill for some 
> resource that is actually being provided. Then it is clear 
> when and how much to bill. So bill for name resolution, or 
> forwarding, or media relaying when
> 
> it adds value (as for anonymization), or conference mixing, etc.
> 
> The time it gets ugly is when you are billing for something 
> intangible -
> 
> where the service provider is adding no real value. That is 
> when you have to make up a name that you can declare is a 
> "service" and charge for.
> 
> [AA] In my view its not the role of SIPPING to determine 
> business models used by service providers. I think that is a 
> matter for the market place and/or regulators and the 
> technology should not restrict or prevent any of the possible 
> business models. When you buy an airline ticket the price of 
> the ticket does not simply reflect the cost of your share of 
> the staff, maintenance overhead and the fuel used to fly you 
> from A to B. The difference in price of your ticket and of 
> that of the person in the seat next to you may be in the 
> order of 3x or 5x or even 10x!
> Basically what is charged is based on what the market rate is 
> for the service and there are different rates for different 
> markets. Depending when and where you buy the ticket can 
> significantly impact the price as does the flexibility of the 
> ticket. Similarly for telecommunications depending on the 
> market for the service the charging may be different, there 
> may be marketing promotions, if you make commitments for 
> minimum usage per month then you may get a much better rate 
> than if you are charged on a per usage basis. Also remember 
> that for mobile phones the service providers often heavily 
> subsidize handsets and then recoup the cost through usage charges.
> 
> > Although Telephony and Push To talk share a similar 
> characteristic in 
> > that they both exchange audio communication they can be considered,
> sold 
> > and deployed as different "communication services". The user
> experience 
> > and understanding of these services is different even is they both 
> > involve audio communication. Likewise you could deploy instant
> messaging 
> > and Push to talk as part of the same "communication service" even
> though 
> > they don't exchange the same media as from a user experience
> perspective 
> > they can be perceived as messaging style communication.
> 
> I agree that the UI for PTT may be different than that for "regular" 
> audio. It is also true that there can be differing UIs for 
> regular audio. (Regular audio on a PC is likely to have a 
> vastly different UI than on a cell phone.) I don't know if 
> these are different "services" on
> 
> the device, or different manifestations of the same service 
> on differing
> 
> devices. But I am quite confident that these do not need to be
> *signaled* as different services.
> 
> [AA] Three reasons why they need to be signaled - hosting of 
> network service logic on different application servers, 
> prioritization of requests and resources on a per service 
> basis and differential charging for those services.
> 
> I thing PTT and regular voice are just different 
> capabilities, that may be packaged together or separately 
> depending on the chosen UI. In the case of these two 
> capabilities I find it hard to think that I even want to 
> think of them as very distinct. I think they are likely 
> better thought of as modalities, similar to the choice of 
> using the headset or speakerphone. If they are being thought 
> of as separate and mutually exclusive applications, it is 
> probably because of development expendiencies, or simply as a 
> means of justifying price gouging, rather than because of any 
> solid engineering rationale.
> 
> [AA] There is also the concept of signing up for different 
> services. If I don't have as part of my service contract PTT 
> then I may not be entitled to use that service. Similarly if 
> I don't want PTT service then why should I be forced to pay 
> for it if I only want standard telephony.
> I think price gouging is an issue for market competition and 
> regulators not for the technology to solve.
> 
> > A call for emergency assistance although similar in many 
> respects to a
> 
> > telephone call is not the same and has different 
> characteristics such
> as 
> > the need to be routed to a particular PSAP based on the callee's 
> > location, the automatic providing of location information to the 
> > emergency responder, the disabling of the interactions with 
> some other
> 
> > telephony features, prioritized signaling and resource 
> reservation and
> 
> > zero based charging. Thus an Emergency service is different to a 
> > Standard Telephony service.
> 
> Yes, this is a feature with some specialized behavior and 
> treatment. But
> 
> I don't think we can put this one into any particular mold, 
> because the characteristics are governed by many 
> irrationalities dictated by legislators (who are known to be 
> particularly irrational.) I hesitate to
> 
> draw many conclusions about how to do anything else based on 
> this particular data point.
> 
> > In SIPPING and ECRIT we have been discussing supporting Emergency 
> > Services and there are proposals to define a services URN 
> to identify 
> > the Emergency Service. The use of this service URN could also be 
> > extended to also cover other Communication services defined by
> standards 
> > organizations (e.g 3GPP, OMA, TISPAN...), Service providers (MSN,
> Skype 
> > etc) and local government, academic institutions and private 
> > corporations. Possibly this is part of the Communication Service 
> > Identifier solution.
> 
> This may indeed be a solution for some parts of the problem. 
> In some ways it can be considered similar to the IMS concept 
> of a PSI, but the routing is potentially even more flexible 
> than that. In particular, I think this is well suited to 
> identifying *targets* that have particular properties without 
> having to explicitly locate them. For instance this might be 
> an excellent way to target a request toward a conference factory.
> 
> > Currently the problem of identifying a communication 
> service has been 
> > resolved by bodies such as OMA simply defining feature-tags for
> Services 
> > and including them in the Accept-Contact header. For 
> instance OMA PoC 
> > has defined a +g.poc.talkburst tag and terminals and 
> servers include 
> > this tag in the Accept-Contact of all initial requests.
> > 
> > The semantics of Accept-Contact as I understand them are 
> really only 
> > related to the matching of a feature set predicate to a capability
> set. 
> > These predicates can be quite complicated and simply including a
> feature 
> > tag as a service identifier in an Accept-Contact header seems to be
> both 
> > overload and extend the scope of what was intended in RFC 3840/3841
> and 
> > cause potential interactions that could significantly 
> restrict the use
> 
> > of complex predicates.
> > 
> > Now +g.poc.talkburst can be considered as an expression of a
> preference 
> > to reach a device that is OMA PoC talkburst control capable 
> which is 
> > necessary for OMA PoC and hence compatible with the semantics of 
> > Accept-Contact. However in PoC this tag is also included in 
> Subscribes
> 
> > to the conference state event package and other messages such a
> Publish 
> > that are sent to PoC Servers that are not directly related to or
> really 
> > requiring talkburst control or even destined to reach the PoC
> terminals. 
> > In this case the Accept-Contact header is being overloaded to just 
> > transport a tag that can be used by Filter Criteria as a trigger to 
> > route to the PoC server and to associate this request as 
> being part of
> 
> > the PoC Communication Service for charging and policy purposes.
> 
> I agree with all of the above.
> 
> > Now OMA is also developing OMA IM based on SIMPLE and we 
> will end up 
> > with something like +g.im.messaging tags included everywhere with
> that. 
> > If we don't come up with an appropriate mechanism that 
> satisfies the 
> > requirements then this hacked solution will become the default
> standard. 
> > So I think developing a documented IETF solution is appropriate and 
> > necessary. Otherwise what is likely to happen is that 3GPP 
> will simply
> 
> > rubber stamp the OMA mechanism which then will be adopted 
> by TISPAN, 
> > Packetcable and everyone else that will use IMS. There is a real
> danger 
> > that the ability to define feature tags and include them in 
> > Accept-Contact becomes a way to extend SIP in proprietary and 
> > non-interoperable ways outside the SIP change process defined in RFC
> 3427.
> 
> This concerns me a lot.
> 
> And I fail to see why it is required at all. IM (at least 
> using MSRP) is
> 
> just like voice from a sip perspective, except that the 
> m-lines and some
> 
> a-lines in the SDP are different. Why is any more than that 
> required???
> 
> > Many of the requirements that are listed for the IMS Communication 
> > Service Identifier seem not to be compatible with the 
> current defined 
> > semantics of feature tags in Accept-Contact. In fact only 
> requirement
> 11 
> > seems to fully match the semantics of a feature tag in 
> Accept-Contact.
> 
> > Requirement 4 on invoking services through some intermediate node 
> > between the endpoints seems to be clearly out of the scope of the 
> > current semantics of Accept-Contact as is requirement 10 on
> authorizing 
> > the request based on the Communication Service Identifier.
> > 
> > There is also the requirement for invoking applications at 
> endpoints 
> > based on the IMS Service Identifier and this needs to be considered
> and 
> > the solution documented within IETF so that it will be generally
> applicable.
> 
> If you insist on designing UEs that have mutually exclusive 
> applications
> 
>   hiding behind the same registration, then I think the 
> straightforward thing to do is act as if the UE is a proxy 
> with a number of UAs behind it. Potentially fork the request 
> to them all. Apply caller preferences, to choose which of the 
> apps best meets the caller's desires, and use whatever other 
> heuristics you wish to break ties or meet the callee's preferences.
> 
> > I also share Jonathan's and other concern that this is not used to 
> > create a situation where applications cannot interoperate between 
> > different domains. Requirement 12 addresses this issue 
> however having 
> > SIPPING work on the problem should be a way to help ensure this
> doesn't 
> > happen.
> 
> I don't speak for sipping, but IMO, using *a* service 
> identifier to do this demultiplexing just guarantees that you 
> can't talk to a device that
> 
> doesn't understand the feature names you use, even though it 
> could provide a reasonable user experience using the 
> protocols it supports.
> 
> At first I thought the IMS notion of Service (Identifier) was 
> quite a bit different than the kind of services that are 
> discussed in the presence work. But we had great battles 
> before arriving at the concepts we did, and some of the 
> positions coming in to that were remarkably similar. So I 
> think we are about to revisit the whole thing again.
> 
> Ideally we can avoid that and just invoke the answer we came 
> up with. If
> 
> not, maybe we have to reconstitute the design team that ended 
> up at that
> 
> conclusion.
> 
> 	Paul
> 
> > Andrew
> > 
> >  
> > 
> > *From:* Stephen Terrill (E2/EEM) 
> [mailto:[email-masked]]
> > *Sent:* Thursday, March 16, 2006 7:43 AM
> > *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-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 
> > 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>
> > 
> >  
> > 
> >
> --------------------------------------------------------------
> ----------
> > This transmission (including any attachments) may contain 
> confidential
> 
> > information, privileged material (including material 
> protected by the 
> > solicitor-client or other applicable privileges), or constitute 
> > non-public information. Any use of this information by anyone other
> than 
> > the intended recipient is prohibited. If you have received this 
> > transmission in error, please immediately reply to the sender and
> delete 
> > this information from your system. Use, dissemination, distribution,
> or 
> > reproduction of this transmission by unintended recipients is not 
> > authorized and may be unlawful.
> > 
> > 
> >
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > 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
> 
> 
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.
> 
> _______________________________________________
> 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