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

From: "Andrew Allen" <[email-masked]>
Date: Fri, 16 Feb 2007 16:39:41 -0500

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

________________________________

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

Andrew,
 
Well, an AS is just another contact (perhaps a permanently registered
one, rather than one that uses SIP REGISTER), isn't it? So caller
preferences can be used to choose an AS or any other contact that
supports the desired capability.
 
I agree caller preferences is not a suitable basis for charging. Just
because I say I have a preference for a contact that supports video,
doesn't mean that I will necessarily use video during that call. That
might be determined during some mid-call session-re-negotiation. Surely
charging has to be based on what is actually used, not what might be
used, and you can't always determine this at INVITE time.
 
So I am saying use caller preferences to select a preferred contact, use
SDP to negotiate and re-negotiate the session with the contact that you
end up with. I haven't heard any compelling arguments for anything else
so far.
 
John

________________________________

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

	John,
	 
	If Service Identification was only about selecting the
appropriate contacts from those registered agaisnt the AOR then RFC
3840/3841 would be fine however Service Identification is much more than
that and may be used to route requests to application servers for
service logic invocation, and used as the basis for charging.
Accept-Contact is basically just a filter expression to filter a set of
registered contacts. Including a parameter in a filter expression and
using that as the basis for charging, authorisation and service
invocation is going to cause problems.
	 
	Andrew
	 
________________________________

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