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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Apr 2006 16:52:08 -0400

Andrew,

I started this response just before the end of the ietf meeting, and 
never finished it. The whole conversation has gotten a bit stale, but 
maybe it is time to revive it. Maybe some others will have opinions now.

See inline.

	Paul

Andrew Allen wrote:
> 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.

This seems trivial as long as there is indeed a PoC *server* in the
call, however it gets there. Once it is involved and doing something it
can generate the needed accounting records. It can also insert other
headers into the request, for the attention of *it's* S-CSCF to indicate
this if it wishes. This need not impact the UEs or the nodes in the
other end of the call.

For instance you may have the PoC service, billed as above, and call me.
I may have signed up for the PTTv2 service, that can interoperate with
your service, and is free from Google. As long as the PTTv2 service
knows how to handle the signaling and media it should be fine, even
though it isn't aware of the PoC service.

Another thing: you say you want to identify that a sip request is 
related to PoC as opposed to telephony or messaging. But why are these 
mutually exclusive? I might want to do *both* messaging and PoC, or PoC 
transitioning to regular telephony, in a single call. You can bill for 
these however you want, but it is very restrictive if you force these to 
be mutually exclusive.

This is also related to the oft mentioned folly of trying to base all 
billing on signaling. The majority of the value of the call is typically 
related to media, so it would make much more sense to base the billing 
on the media than the signaling. If you must, charge one rate for PoC 
media, another for "telephony" media, and another for "messaging" media. 
Then it doesn't matter if they are in the same call or not.

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

That's fine. But why design the architecture so that the application
running in the UE must have a 1:1 relationship to network based
services? There can be UE applications that require nothing "special" in
the network, or that provide a common UI to multiple independent network
based services.

If the service is provided entirely by the application in the UE (e.g. 
an alarm clock service) then there may be a challenge doing usage 
pricing on it. (Not impossible, but a challenge.) If the basic service 
is provided by something in the network, and the application in the UE 
simply provides a UI for it, then either you can just do network 
changing for the network component, or you can view it as two things 
that may each result in a charge.

In any case, I still don't see why all of these different concepts need 
to be conflated.

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

So I should have to choose one service if I want "traditional voice
services", which restricts me to calling others that have the same
service? And choose some different service to call somebody that has
only "telephony services"?

In practice you are going to have to learn the capabilities of the
target you are calling by attempting the call and seeing what works. 
This is one of the compelling reasons for having primitive 
*capabilities*, and if "services" are thought to be important then 
considering certain groupings of those capabilities to be "services" 
from the point of view of one UE or provider. It is not necessary that 
all parties in a call understand the same set of services - only the 
same set of capabilities.

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

So are you saying that the service identifier is only useful between the
call originator and the originating proxies and ASs? That would be an
improvement.

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

I agree this is not something that you will typically present to an end
user directly. But it is something for the UI of the device to manage.
And some things certainly are managable by the end user if handled
correctly, and may be even easier than grouped services.

For instance, is it better to have an audio service and an audio/video
service? Or is it better to just let the user make the call and turn the
camera on/off to control the inclusion of video in the call? I would
choose the latter.

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

Are we trying to specify something used by programmers in programming
the signaling application? Or are we designing the UI of an application?

It seems you are trying to do both at once, and I think that is a
mistake. Yes, the designer of the UI will have to manage the number of
concepts that the end user is expected to understand. This is
specialized task, and will differ depending on the kind of user as well
as the capabilities of the device.

We can expect more competence from the programmer of the application.

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

The good thing about these classifications is that we don't have just
one. We have lots of different classifications for different purposes.
E.g. "barnyard animals", "pets", "flying creatures". And many of the
classification systems, such as the one you mention, are hierarchical,
so it is possible to be as specific or general as desired.

The concept of "service" that I think is being proposed isn't like this. 
It seems the intent is for it to be an enumeration of mutually exclusive 
possibilities. The world isn't that black and white.

> As a User I need to
> have an easy way to understand how I will be charged for using some
> capability.

The billing system needs to be comprehensible to the user in the context
of things that the user is aware of. But that doesn't mean just "which
application am I using". It can include things like "how many times did
I "push to talk", or "how long did I have my camera on during a call".
As with the services themselves, the designer of the UI needs to be
aware of the intended billing model(s) and present things in a
comprehensible way. But I fail to see how this implies a single "service
identifier" per call.

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

You can construct the UI with whatever groupings make sense in the 
context of the service agreement between the user and his provider. IMO 
an architecture that assumes exactly one "service" per call is unduly 
restrictive. For instance I would like to have the option to start with 
a voice call and then add video midway into the call. I am sure that 
some comprehensible way can be found to bill for such a feature. I 
shouldn't have to decide at the beginning of the call whether I want to 
use video. Nor should I have to pay for video in calls where I don't use it.

Even more important is that caller and callee should not have to agree 
on the definition of the services in order to use the capabilities that 
make up the service. The two ends should be able to use any capabilities 
they have in common even if they don't agree on the name of the service 
that contains those capabilities, or even on the concept of "service".

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

Yes, I agree with this. OTOH, SIPPING doesn't have to go out of its way 
to facilitate the arbitrary restrictions in service.

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

Sure. Mostly you are talking about volume discounts and discounts for 
committing in advance to a certain minimum level of usage. This is a 
great way for the provider to manage capacity efficiently, and can be a 
good deal for the buyer as well.

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

If that is they way customers want to have things packaged, then go 
ahead and do it that way. But does the system architecture have to be 
structures so it *must* be packaged that way?

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

One again I am beating the dead horse...

There is no obvious reason why there need be any relationship between 
the UI and the signalnig. Or that the signaling necessarily need be 
tightly coupled to the billing.

There does need to be enough in the signaling, or otherwise determinable 
by network elements, to do what needs to be done, and to generate 
appropriate accounting for what has been done. But these need not be 1:1 
with UI features. They can be 1:n or n:1 or n:m.

For instance, if I happen to be making an audio/video call isn't it 
sufficient to be able to tell that both audio and video are being 
requested? Depending on the service agreement this might be billed as 
one combined rate for an audio/video call, or as a separate charge for 
the audio and video parts. And the callee may get charged as well, on 
the same or a different basis.

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

That is fine. But are those mutually exclusive services you sign up for? 
Or just potential options that may be used, in various combinations, in 
calls if you have signed up for them.

So if I haven't signed up for video then I can't use it. If I have 
signed up for video, then it may be used at the beginning of a call, or 
brought in in the middle of a call, in combination with other things I 
might also have signed up for, such as IM.

It may be that the implementation of PTT is that it just doesn't mix 
well with other services. But hopefully that is the exception rather 
than the rule.

I also might argue that in an environment like cable access, where I 
have signed up for some best-effort bandwidth, then I ought to be able 
to use features like video in my call on a best effort basis even if I 
have not signed up for the extra-cost video service. OTOH if I sign up 
for that service then I may be entitled to some guaranteed QoS. So it 
may be that what I sign up for is not the feature, but for a better 
guarantee of service for that feature.

	Paul

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