Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio ninSIP

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Feb 2007 08:33:52 +0000

Resending with some truncation (was too big to go through without moderator
approval).
#########################################################################
 
Andrew,
 
OK, so it seems you are talking about IMS Application Servers. I don't see
this mentioned in Jonathan's draft, the emphasis of which seems to be on
application selection at the terminating device. For example, in section 9,
4th paragraph it states:
"Firstly, they are meant specifically and exclusively for usage in cases
where some service logic must be present and matching on both the
originating and terminating sides in order for any type of reasonable
communications to exist."
This seems to preclude use by any network intermediaries. So when I talked
about an AS, I meant a terminating side entity. So while I definitely agree
that SDP is not suitable for use by intermediaries, it would be legitimate
for a terminating application to make use of it. Also caller preferences is
suitable for selecting between different terminating entities.
 
I have still not been convinced by arguments for having a service identifier
that can be used by intermediaries, but one possibility has emerged from
these discussions that I might be able to buy. It seems there might be some
need to convey some higher level "purpose" for a request that might
influence routing decisions at SIP intermediaries, in addition to being used
by the UAS. I think one example cited was push-to-talk (PTT), which might
want to avoid being subject to call forwarding that normal INVITE requests
might undergo. A user may be able to arrange that his local proxy retargets
or forwards requests under certain conditions. If a call were marked as
"PTT" or "chess", the user could arrange that such calls be subject to
different rules. So the called user (or an administration acting on the
called user's behalf) decides on the rules, which can take into account
whatever the calling user claims to be the purpose of the call. I am not
sure about the security implications here, because the caller might get to
learn what to do to get around retargeting imposed by the callee.
 
Furthermore, I am not convinced by the notion of authorisation or charging
being based on such a service identifier unless there are some appropriately
strong security mechanism to prevent misuses by the caller. Charging on the
basis of a service identifier is fine if the network really provides some
added value that it would not provide in the absence of that service
identifier. But given that network intermediaries cannot examine the SDP, it
it not clear exactly what added value might be provided. In the absence of
any value added by the network, uses would not use the service identifier
and therefore avoid higher charges (presumably finding some out of band
means to inform the called user of the wish to use a particular service).
This is where we still seem to lack compelling examples. 
 
John

  _____  

From: Andrew Allen [mailto:[email-masked]] 
Sent: 16 February 2007 19:59
To: Elwell, John; Malleswara Rao Ankem
Cc: [email-masked]
Subject: RE: Device architecture? WAS: RE: [Sipping] Service Identificatio
ninSIP

John
 
I think whether an AS in the terminating network is considered a contact is
a debatable point. Certainly it doesnt register feature tags using RFC 3840
mechanisms and (at least in IMS) they dont show up as registered contacts in
the reg-event notifications. Also AS in the originating network (which may
need to be involved in some communication services) are certainly not
contacts for the resource identified by the Request-URI and Accept-Contact
certainly has no defined role in routing to them.
 
In addition 3GPP TS 23.228 v7.6.0 subcaluse 4.13.2 specifies 15 requirements
for IMS Communication Service Identifier and only one of these is regarding
matching to the correct contact:
 
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).

 Several of the other requirements are in my view totally incompatible with
Accept-Contact being the transport for the identifier and indeed may limit
the use of Accept-Contact for its intended purpose. This includes charging
and policy control:
 
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.

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

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.

Another problem with UAs placing feature tags in Accept-Contact headers as
Service Identifiers is how does the initiator obtains the service identifier
of the destination party for the related service? The concept only works in
the scenario where all networks and devices have a common understanding of
the same services and the identifiers that identify them. As far as I am
aware SIP doesnt provide a mechanism to discover proprietary non standard
feature tags that are used by other devices in other domains and map them to
services that they relate to. This means that if Accept-Contact is used the
communication services are closed and can only be used by those who are part
of the closed network, (unless of course IETF were to get into standardising
services which I think is highly unlikely). If URIs are used as the
container for the Service Identifier these can be obtained using Presence as
proposed in Jonathan's draft.
 
This helps fulfil the following requirements in 3GPP TS 23.228:
 
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.

14. The usage of communication service identifiers shall not restrict the
inherent capabilities of SIP.

SDP is not good for routing decisions for service identification. Firstly
SDP is intended to be end to end only. It may be encrypted and understanding
the details of the service may require service or application level
understanding of the SDP and the service which is knowledge that proxies
should not need to have. Also I dont think that SDP can always uniquely
identify a service in any case. In addition not all requests that are
related to a service will contain SDP in any case.
 
Andrew

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Feb 2007 13:10:34 -0500

Elwell, John wrote:

> I have still not been convinced by arguments for having a service 
> identifier that can be used by intermediaries, but one possibility has 
> emerged from these discussions that I might be able to buy. It seems 
> there might be some need to convey some higher level "purpose" for a 
> request that might influence routing decisions at SIP intermediaries, in 
> addition to being used by the UAS. I think one example cited was 
> push-to-talk (PTT), which might want to avoid being subject to call 
> forwarding that normal INVITE requests might undergo. A user may be able 
> to arrange that his local proxy retargets or forwards requests under 
> certain conditions. If a call were marked as "PTT" or "chess", the user 
> could arrange that such calls be subject to different rules.

As soon as I discover you have done that, I will start to mark my calls 
as PTT any time I want to avoid having them forwarded, even though they 
aren't PTT calls.

For this, I think one might as well admit that you are opening the 
forwarding to caller preference, and simply use caller preferences for it.

	Paul

> So the 
> called user (or an administration acting on the called user's behalf) 
> decides on the rules, which can take into account whatever the calling 
> user claims to be the purpose of the call. I am not sure about the 
> security implications here, because the caller might get to learn what 
> to do to get around retargeting imposed by the callee.
>  
> Furthermore, I am not convinced by the notion of authorisation or 
> charging being based on such a service identifier unless there are some 
> appropriately strong security mechanism to prevent misuses by the 
> caller. Charging on the basis of a service identifier is fine if the 
> network really provides some added value that it would not provide in 
> the absence of that service identifier. But given that network 
> intermediaries cannot examine the SDP, it it not clear exactly what 
> added value might be provided. In the absence of any value added by the 
> network, uses would not use the service identifier and therefore avoid 
> higher charges (presumably finding some out of band means to inform the 
> called user of the wish to use a particular service). This is where we 
> still seem to lack compelling examples.
>  
> John
>  
> 
>     ------------------------------------------------------------------------
>     *From:* Andrew Allen [mailto:[email-masked]]
>     *Sent:* 16 February 2007 19:59
>     *To:* Elwell, John; Malleswara Rao Ankem
>     *Cc:* [email-masked]
>     *Subject:* RE: Device architecture? WAS: RE: [Sipping] Service
>     Identificatio ninSIP
> 
>      
>     John
>      
>     I think whether an AS in the terminating network is considered a
>     contact is a debatable point. Certainly it doesnt register feature
>     tags using RFC 3840 mechanisms and (at least in IMS) they dont show
>     up as registered contacts in the reg-event notifications. Also AS in
>     the originating network (which may need to be involved in some
>     communication services) are certainly not contacts for the resource
>     identified by the Request-URI and Accept-Contact certainly has no
>     defined role in routing to them.
>      
>     In addition 3GPP TS 23.228 v7.6.0 subcaluse 4.13.2 specifies 15
>     requirements for IMS Communication Service Identifier and only one
>     of these is regarding matching to the correct contact:
>      
> 
>     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).
> 
>      
>      Several of the other requirements are in my view totally
>     incompatible with Accept-Contact being the transport for the
>     identifier and indeed may limit the use of Accept-Contact for its
>     intended purpose. This includes charging and policy control:
>      
> 
>     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.
> 
>     Also:
>      
> 
>     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.
> 
>     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.
> 
>     Another problem with UAs placing feature tags in Accept-Contact
>     headers as Service Identifiers is how does the initiator obtains the
>     service identifier of the destination party for the related service?
>     The concept only works in the scenario where all networks and
>     devices have a common understanding of the same services and the
>     identifiers that identify them. As far as I am aware SIP doesnt
>     provide a mechanism to discover proprietary non standard feature
>     tags that are used by other devices in other domains and map them to
>     services that they relate to. This means that if Accept-Contact is
>     used the communication services are closed and can only be used by
>     those who are part of the closed network, (unless of course IETF
>     were to get into standardising services which I think is highly
>     unlikely). If URIs are used as the container for the Service
>     Identifier these can be obtained using Presence as proposed in
>     Jonathan's draft.
>      
>     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.
> 
>     14. The usage of communication service identifiers shall not
>     restrict the inherent capabilities of SIP.
> 
>      
>     SDP is not good for routing decisions for service identification.
>     Firstly SDP is intended to be end to end only. It may be encrypted
>     and understanding the details of the service may require service or
>     application level understanding of the SDP and the service which is
>     knowledge that proxies should not need to have. Also I dont think
>     that SDP can always uniquely identify a service in any case. In
>     addition not all requests that are related to a service will contain
>     SDP in any case.
>      
>     Andrew
> 
> 
> ------------------------------------------------------------------------
>