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

From: <[email-masked]>
Date: Mon, 20 Mar 2006 18:03:21 +0530

hi Stephen,
 
based on the requirements 3, 4, 5 I understand the need for this
identifier to be able to identify the service and the application to
handle it
at various nodes like the UE, S-CSCF, AS.
 
however, the following paragraph in your mail confuses me. can you
please explain further?
 
> Please note that this is not intended to identify service that are 
> routed to, such as train time tables etc.  For these services, the 

> communication services is a means to route to and reach the ultimtate 

>end-user service.  This discussion is about how to identify the 

> communication service.

thanks,
Ravi.

________________________________

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

Hello All, 

I am of the understanding that there have been some questions regarding
the requirements for the identification of IMS services.  I would like
to provide an understanding of the 3GPP discussions on this topic.  As I
see it, the need to identify the IMS communication services stems from
that we have/are devloping different services on IMS as a SIP
infrastructure, such as push-to-talk over cellular (PoC) or messaging.
As there are different services and as it is not safe to rely on the
expressed media as the media may be used in different services then
there is the need to identify the service that is requisted.  This could
be seen as a means to identify the context upon which to interpret the
SIP signalling.  This is required to e.g. Identify the application
server that supports this communication service and to identify the
client to invoke in the terminating network.  While writting this, I
seem to recall a parrallel discussion in relation to presence, and that
was along the lines that was that it was required to identify the
service that was used to communicate in the presence, as otherwise two
if the same presence information appeared for two incompatabile services
(e.g. two incomptable versions of push to talk) which fulfulled the same
end-user expectation appeared the same in presence, then the end-user
would get confused as to why s/he could communicate with some users but
not with others.

Please note that this is not intended to identify service that are
routed to, such as train time tables etc.  For these services, the
communication services is a means to route to and reach the ultimtate
end-user service.  This discussion is about how to identify the
communication service.

This has been discussed at an architectural level within 3GPP and a
Technical Report has been produced.  The Technical report can be found
at http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip
<http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip> .  This has
been moved to approved status this week.  The essence of this technical
report has been included in specification text which can be captured in
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060468
.ZIP
<http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-06046
8.ZIP>  and
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060469
.ZIP
<http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-06046
9.ZIP>  .  Note that the changes included in S2-060468.ZIP are changes
to what was already included in the specification text last year.  These
documents represent the approved requirements within 3GPP.

I can appreciate that a number of readers prefer to read this in text
instead of word, as such the approved 3GPP text that has been included
in the specifications is included below.  As such, the text below are
the 3GPP stage 2 representation of the requirements.  It is worth
keeping in mind that the text below represensts archtectural
requirements and not the protocol realisation of these requirements.

Please don't hesitate to contact me if you have any questions. 

I apologies in advance to the references to the 3GPP interfaces, they
are retained as I though it was better to avoid modifying any of the
agreed text when copying it into this email.

Best Regards, 

Stephen Terrill 

<Specification Text> 
4.13.2  Identification of IMS communication Services 
A communication service identifier provides a framework for the
identification of IMS communication services utilising the IMS enablers.
An IMS communication service is provided via the use of the IMS
enablers. At terminals, the use of a communication service identifier is
similar to the use of the port concept in TCP/IP, in that it allows
applications in a terminal and the network that use SIP for
communication purposes to be identified. In the terminal this means
dispatching a SIP message to the correct application, and in the network
it means selection of the correct application server over ISC. Examples
of IMS based applications and communication services are OMA messaging
and OMA PoC.

The communication service is an aggregation of one or several media
components and the service logic managing the aggregation, represented
in the protocols used. Its behaviour and characteristics may be
standardized as done for the two examples above, or proprietary and
specific for e.g. an operator or an enterprise.

A service description specifies this behaviour and states e.g. the
allowed media combinations and state transitions as a consequence of
signalling and use of IMS enablers in the network and terminals.

The need of applying a service identifier is to be taken within the
specification of each individual service. 
The communication service identifier identifies IMS communication
services and shall be included in the relevant SIP methods.

The IMS communication service identifier shall fulfil the following
requirements: 
1. It shall be possible for the UE and an Application Server (AS) to set
the 
   IMS communication service identifier in a SIP request, e.g. in the 
   REGISTER and INVITE request. 
2. Based on operator policy the S-CSCF or an AS shall be able to
validate an 
   IMS communication service identifier in a SIP request. This includes
e.g. 
   to check the syntactical correctness of a service identifier, and
policing 
   the usage of a communication service identifier. 
3. It shall be possible, e.g. for the UE, S-CSCF and AS, to identify an 
   IMS service uniquely by the IMS communication service identifier. 
4. It shall be possible for the S-CSCF to invoke appropriate service 
   logic based on the IMS communication service identifier contained 
   in a SIP request, e.g. route a SIP request containing a service
identifier 
   based on initial filter criteria to the correct AS. 
5. It shall be possible for the UE to invoke appropriate application 
   based on the IMS communication service identifier contained in a 
   received SIP request. 
6. It shall be possible for the UE to indicate its service capabilities 
   to the network, e.g. during registration, using the 
   IMS communication service identifier. 
7. The structure of the IMS communication service identifier shall be as

   simple as possible, i.e. the IMS communication service identifier
shall 
   be limited to identify a service. 
8. Based on operator policy S-CSCF and AS shall consider the 
   IMS communication service identifier for online and offline charging,

   e.g. put appropriate data into call detailed records. 
9. The communication service identifier shall be capable of being an 
   input into the policy control and charging rules. 
10. It shall be possible to use the IMS communication service identifier
as 
    a means to authorise whether a subscriber is allowed to initiate or 
    receive request for a communication service. 
11. The communication service identifier shall be taken into account 
    when selecting the correct UE(s), if multiple UEs are registered 
    for the same Public User Identity(s). 
12. The usage of communication service identifiers shall not adversely 
    affect interoperability between IMS networks and interoperability 
    with external SIP networks and CS networks. The behaviour of a
network 
    receiving the IMS requests without an IMS communication service 
    identifier is a matter of operator policy. Usage of communication 
    service identifiers shall not decrease the level of interoperability

    with networks and UEs that are unaware of the communication service
identifier. 
13. It shall be possible for the IMS network and UE to support
communications 
    that do not use a communication service identifier. In the case that
an 
    IMS communication service identifier is not present then the network
may 
    assume a particular IMS communication service. 
14. The usage of communication service identifiers shall not restrict
the inherent 
    capabilities of SIP. 
15. The usage of communication service identifiers shall not require
additional user 
    interaction, i .e. the communication service identifier is assumed 
    to be "added" by the UE that initiates the communication. 

The network and the terminal shall be able to continue operation as
defined in 3GPP Release 5 and 3GPP Release 6. 

The communication service identifier shall be available at least in the
following interfaces: 
-       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; 
-       Cx; Dx (e.g as part of the iFC); 
-       Rx; 
-       Rf, Ro. 

NOTE:   The communication service identifier does not replace the 
public service identity (PSI). The communication service identifier
would be used to indicate the communication service used to access the
service addressed via a PSI, and is required to identify the
communication service even when SIP requests are sent towards another
entity without using a PSI.

4.13.2  Identification of IMS applications 

An IMS application is an application that uses an IMS communication
service(s) in order to provide a specific service to the end-user.  The
IMS application uses specific IMS Communication Service(s) and provides
the end user service through the reuse of the SIP communication part of
service. The IMS application does not extend the definition of the IMS
communication service.  The IMS application reference identifies the
application utilising the IMS communication service.

<< removed figure >> 

Figure 4.13-1:  IMS applications on top of an IMS communication service
The IMS application reference is used to identify the IMS applications
other than the default for the IMS communication service.  The IMS
application reference has significance at the UE and the SIP AS behaving
as SIP endpoints.  The means to transport the IMS application reference
is defined within the IMS communication services.  When used, it shall
be possible to transport the IMS application reference on at least on
the following interfaces:

*       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf 

</Specification Text> 

_______________________________________________
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: "Andrew Allen" <[email-masked]>
Date: Thu, 23 Mar 2006 07:28:23 -0500

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

> at http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip.  This
has 
> and 
> .  Note that the changes included in S2-060468.ZIP are changes to what

> was already included in the specification text last year.  These 

> identification of IMS communication services utilising the IMS 
> enablers.  An IMS communication service is provided via the use of the

> IMS enablers. At terminals, the use of a communication service 
> identifier is similar to the use of the port concept in TCP/IP, in
that 
> it allows applications in a terminal and the network that use SIP for 

shall
> 10. It shall be possible to use the IMS communication service
identifier as
network
>     that do not use a communication service identifier. In the case
that an

> *       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf
------------------------------------------------------------------------
> 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.
> 
> 
>
------------------------------------------------------------------------

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

---

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Mon, 27 Mar 2006 08:49:12 +0200

Hi Keith,

This was in the context of PoC as an "Enumerated services" - in this
manner, PoC and messaging are a bundling of capabilities.

Best Regards,

..//Steve 

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Sunday, March 26, 2006 6:25 PM
To: Stephen Terrill (E2/EEM); Paul Kyzivat
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Gonzalo Camarillo (JO/LMF)
Subject: RE: [Sipping] Requirements for the identification of IMS
communicationservices.

I am not aware that 3GPP specifies how any of these capabilities are
partitioned up to application servers.

In particular for the telephony application server that I know you keep
referring to, this is based on the current TISPAN specifications for
provision of services using ISDN supplementary service definitions.
TISPAN has not indicated any requirement to place all these on a single
application server.

That may be the manner that a vendor chooses to package these to sell,
but it is not what the specifications say.

regards

Keith

> Sent: 21 March 2006 19:06
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; Gonzalo Camarillo (JO/LMF)
> Subject: RE: [Sipping] Requirements for the identification of IMS 
> communicationservices.
> 
> 
> 
> Hi Paul,
> 
> >What is supposed to happen when interoperating with users that don't
> have the same concept of how to >partition capabilities into services?
> 
> This is what I thought that the identifier is to solve.
> 
> 
> 
> 
> So far, PoC; Messaging and Telephony have different applications 
> servers supporting them - they can, as an option, by combined, but not

> required
> - do you agree with that?
> 
> Best Regards,
> 
> Stephen Terrill
> 
> 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
>