Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Sat, 17 Feb 2007 22:15:48 -0500

Hi Henning,

First point on the use of Service URNs. I think the following properties
of a URN are important to this work:

a)       the guaranteed uniqueness - we need to ensure that service
identifiers are unique. URNs have an existing process for ensuring
uniqueness.

b)       the ability to use a URN as a URI - A UA can be pre-configured
or through some other means obtain a URN for a given service and then
this can be used in the Route header or the Request-URI in order to
contact Application Servers in the local domain when initiating a
communication related to the service. 

c)       a hierarchical structure - in order to enhance the
interoperability URNs provide the possibility to perform best match
comparisons in order to determine what service should be provided.

e.g  
If 
   URN:service.comm.telephony.multimedia
Is present in a request but only
   URN:service.comm.telephony.basic 
is supported then that can be considered a good match. 

Some of these communication services may also be location based for
example the equivalent of 1-800-PIZZA could be
URN:service.comm.telephony.free.restaurant.pizza.

Linking this to the Service URN used in ecrit seems convenient but not
absolutely essential. 

Secondly I don't have a problem with using Callee Caps and Caller
preferences to find the appropriate UAS however the requirements for
service identification are much more than just that.  

This following requirements from 3GPP TS 23.228 do not I believe fit
well with the semantics of Accept-Contact:

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.

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.

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.

Note that the some of AS (Application Servers) that need to be invoked
based on requirement (4) may not have any relationship to the resource
identified by the Request-URI because they are Applications Servers in
the domain of the originating UAC.

Not only do these requirements not semantically fit with Accept-Contact
but the fact that a service feature tag appears somewhere in an
Accept-Contact cannot be taken as a definitive indication the initiating
user is only requesting that particular service as the expression may
involve other feature tags in a complex expression.

In addition there needs to be a mechanism that allows UAs to obtain the
appropriate service identifiers used by other UAs and in other domains.
I think Jonathan's proposal to use Service URIs and Service Instance
URIs with Presence creates a backward compatible way for UAs to obtain
these identifiers.

Andrew

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Saturday, February 17, 2007 12:27 PM
To: Jonathan Rosenberg
Cc: sipping
Subject: Re: [Sipping] Service Identification in SIP

I think we're in general agreement; in particular, Require seems like  
the right approach. (service URNs do not, in my opinion).

Stepping back, I don't think we should generalize this problem since  
it essentially "blesses" a particular design approach that is  
undesirable. The right approach, from a SIP perspective, for IMS PoC  
would have been to come up with a solution that is backwards- 
compatible. If that's not possible, getting "branded" with Require  
seems like the right penalty.

In general, we have probably two requirements:

(1) When contacting an AOR, a UAC that needs a special UAS to work  
properly needs to get routed to that UAS only. Callee caps and caller  
preferences seem to be the right tools for that, as it involves call  
routing and capability matching.

(2) If, despite doing (1), a SIP request accidentally reaches a UAS  
that can't do anything useful with it, Requires minimizes the damage  
(and allows a proxy to serially-fork to something else that might  
have a chance of working).

Henning

On Feb 16, 2007, at 8:48 PM, Jonathan Rosenberg wrote:

> I think its a fair point that the example is contrived. Really, the  
> main use case being targeted is IMS PoC. So, let me talk a bit  
> about that.
>
> One would think that PoC is just a regular SIP call that has floor  
> control added to it as another media type, and so one could  
> indicate that a call is a PoC call just because of the presence of  
> this new media type in the SDP. Sadly, I wish that were true. If it  
> was, we would not need a mechanism here.
>
> Unfortunately, PoC has layered a whole bunch of additional  
> behaviors into the way SIP requests are handled. Dale has indicated  
> one of them - that a 200 OK is returned on the terminating side  
> priod to the call actually being completed. PoC also *requires* the  
> insertion of servers into the SIP signaling path to make the system  
> work. Consequently, though the messages that PoC uses *look* like  
> SIP messages with a new media type, there is a hidden 'extension'  
> in place that changes the fundamental semantics of INVITE. The fact  
> that this extension is not visible as a specific header in a well  
> defined way does not change the fact that PoC CHANGES THE BEHAVIOR  
> OF SIP AND IS THUS A SIP EXTENSION.
>
> To convince yourself of this, consider what would happen if a PoC  
> client calls a regular SIP phone. The regular SIP phone would see  
> the PoC floor control stream and reject it as unknown. If PoC were  
> just SIP as we've specified it, then everything would be fine, and  
> the call would proceed but without floor control.
>
> But alas, it is not so.
>
> Because PoC makes all kinds of assumptions about the behaviors of  
> its participants, and what the real meaning is for various SIP  
> messages, the entire thing just won't work when a call terminates  
> on a non-PoC device. This is because PoC is, effectively, a fairly  
> significant and non-backwards-compatible extension to SIP.
>
> So, my proposal is, if you are going to go and DO something like  
> that, you better use the SIP techniques that we've defined to deal  
> with it. And when you extend SIP in a way that doesn't work with a  
> SIP endpoint that doesn't understand an extension, you use a  
> Require header. And that is exactly what I'm proposing that 3gpp  
> should do. Use Require because you have made a non-backwards- 
> compatible extension to SIP.
>
> The general problem here is that there are other places where  
> people are layering additional 'context', as Loreto has called it,  
> ontop of SIP signaling. This is a worrisome trend because this  
> context is subtle and not explicitly signaled. Its just assumed.  
> And that is dangerous, since it leads to the kind of balkanization  
> and non-interoperability that myself, Paul, Dale and others have  
> complained about in this thread.
>
> The current 3gpp specs, instead of using Require to signal this  
> extension, put a tag into the Accept-Contact header field. I find  
> this extremely worrisome, because it is really just masking the  
> reality of what has happened. If you've got a situration where a  
> SIP call *cannot be processed* without going through application  
> servers, then this is not something that is signaled with Accept- 
> Contact. Its signaled with Require or Proxy-Require as appropriate.
>
> Thanks,
> -Jonathan R.
>
> Henning Schulzrinne wrote:
>

_______________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 18 Feb 2007 10:36:29 -0500

Andrew,

my concern is that I'm unsure that developing a very generic  
mechanism to address a problem we don't want to happen in the first  
case seems both misplaced effort and counterproductive. A robust and  
distributed allocation mechanism for identifiers makes sense if you  
expect hundreds of entities to independently need to allocate such  
identifiers. This is clearly undesirable in this case, based on the  
examples presented, so the IANA registration mechanism for Require  
tags seems to be both sufficient and sufficiently onerous to prevent  
gratuitous incompatibility.

I also believe that service URNs are wholly inappropriate for this  
particular purpose, even if you don't believe what I wrote above.

Henning

On Feb 17, 2007, at 10:15 PM, Andrew Allen wrote:

> 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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 10:29:12 -0500

I'm on the fence about whether service URN, or just an arbitrary token, 
is appropriate here. I do agree that we want to do this infrequently and 
thus do not have the need for a robust and distributed allocation 
mechanism. In that sense service URN is not necessary. However, it is 
appropriate in that what is being required is understanding of some 
additional context around WHY I'm sending this SIP request; which can 
legitimately be considered the service.

-Jonathan R.

Henning Schulzrinne wrote:

> Andrew,
> 
> my concern is that I'm unsure that developing a very generic  mechanism 
> to address a problem we don't want to happen in the first  case seems 
> both misplaced effort and counterproductive. A robust and  distributed 
> allocation mechanism for identifiers makes sense if you  expect hundreds 
> of entities to independently need to allocate such  identifiers. This is 
> clearly undesirable in this case, based on the  examples presented, so 
> the IANA registration mechanism for Require  tags seems to be both 
> sufficient and sufficiently onerous to prevent  gratuitous incompatibility.
> 
>> b)       the ability to use a URN as a URI - A UA can be pre- configured
>> Not only do these requirements not semantically fit with Accept- Contact
>> 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.
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com