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

From: "Andrew Allen" <[email-masked]>
Date: Wed, 22 Mar 2006 18:22:47 -0500

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"

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

---------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Mar 2006 21:30:17 -0500

Andrew,

Much commentary inline.

	Paul

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

> 
> My definition of a “communication service” is a somewhat arbitrary 
> 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.

> Some service groupings are historical (such as replicating 
> 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.

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.

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.

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

> features grouped or packaged together as “communication services”. 

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.

> together as “communication services” allows them to sell different 
> view that “service based charging” is “evil” but I think it is 
> probably isn’t in my interests as a user to have service providers 
> up paying for all those things that I don’t want or have any use for. It 

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.

> and deployed as different “communication services”. The user experience 
> 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 

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.

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.

> the need to be routed to a particular PSAP based on the callee’s 

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.

> organizations (e.g 3GPP, OMA, TISPAN…), Service providers (MSN, Skype 

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.

> the PoC Communication Service for charging and policy purposes.

I agree with all of the above.

> If we don’t come up with an appropriate mechanism that satisfies the 
> 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???

> 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 
> 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 
> 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 
> 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 
>    simple as possible, i.e. the IMS communication service identifier shall
> 10. It shall be possible to use the IMS communication service identifier as
>     with external SIP networks and CS networks. The behaviour of a network
>     that do not use a communication service identifier. In the case that an
>     to be “added” by the UE that initiates the communication.
> 
> •       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

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Thu, 23 Mar 2006 20:21:00 -0500

One of the central questions of the "service identifier" question is
whether the set of "services" can be reduced to a small, standardized
set.  If not, there are a number of different ways of distinguishing the
service needs of a request, but these methods are mostly equivalent, and
proxies/UAs/etc. have to implement some sort of best-fit algorithm for
servicing requests.  If there really are a small number of standardized
"services", then we can tag requests unambiguously with a simple
"enumeration variable".

In this regard, Andrew Allen speaks in favor of a service identifier:

> together from either a user experience or a service provider business

It seems to me that once you admit that a "service" is "somewhat
arbitrary", you are opening the door to the likelihood that they will
*not* be standardized in practice, which in turn will defeat any simple
"service identifier" enumeration.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Mar 2006 10:09:38 -0600

On Mar 22, 2006, at 5:22 PM, Andrew Allen wrote:

> straightforward means to easily identify that SIP requests are  
> related to a particular communication service.
>
>
>
> 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”
>
>
>
> together from either a user experience or a service provider  
> business perspective. 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.

This offers a good chance to explain what I think people find  
troubling about your phrasing.

1) You make that assumption that "SIP requests are related to a  
particular communication service".

2) You describe POC, "ISDN simulation", and "emergency" as services.

What happens if you want to make a POC call (or an ISDN simulation  
call) to an "emergency" service?

if you can't mix and match services, you're not using SIP. You're  
using some mutant telco protocol that we've little interest in  
discussing here.

--
Dean