Subject: RE: [Sipping] Re: [Sip] Originating Line Information

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 17 Sep 2002 12:33:22 -0400

From a design perspective, I agree that it clearly isn't desirable to have
two ways of doing the same thing, and I also agree that we need a way to
decide when descriptive information belongs in a tel or SIP URI, and when it
belongs in caller prefs. CPC/OLI is certainly a corner case - how or even if
it should be represented in SIP is hardly cut and dry.

Most parameters that we have taken from ISUP and mapped into tel URL
attributes have been directly relevant to routing the request (or, in
deference to the URI crowd, identifying the appropriate resource in the
network). The carrier identification code, number portability information,
and recently, the (destination) trunk group parameters have all fit this
mold. It's important that this information is intended to be consumed by
intermediaries (like proxy servers) that dereference these URLs. As the
SIP-T maxim goes, most information that would not be used by an intermediary
routing the request should be encapsulated (with RFC3204) rather than
translated. So if we do nothing further, IETF practice already has a way to
communicate OLI/CPC end-to-end.

The Originating Line Information / Calling Party's Category isn't as
immediately relevant to routing SIP requests. In the first place, it is an
attribute characterizing the sender of the request, not the target (at least
as its used in the PSTN - in a SIP environment it might make sense to apply
these categories to URIs in other contexts). Moreover, the purpose of
identifying, for example, that a terminal is in prison, is in order to
restrict whom its calls can reach. This information is actually intended to
be used by intermediaries that make a routing decision. In the 'prison'
case, it limits the set of resources that can be selected as destinations
for the call. In another case, the Calling Party's Category can express a
preference to reach an operator who speaks a particular language.

How this would apply to caller/callee preferences is quite interesting.  For
the caller to specify that they would like a German-speaking operator also
sounds like a reasonable application (though isn't there something like this
in SDP as well?). It might make sense for a callee to be able to specify
that they do not wish to receive calls from terminals that are in prison
(using the registration function of caller prefs). So at least some of the
functions of the CPC/OLI map well onto caller preferences.

Others, however, don't. Being in prison, or being a payphone, are not in any
reasonable sense capabilities or preferences - a payphone may have limited
capabilities, but that is orthogonal to the fact that it is a payphone, and
it would probably be better to enumerate those capabilities than to just say
that something is a payphone and hope that the capabilities are understood.
These sorts of facts about the originating terminal are probably something
that would be asserted by an intermediary enforcing some policy, rather than
the terminal itself (being in prison is probably quite at odds with the
caller's preferences, and characterizing a terminal as a prison phone limits
the terminal's utility). It makes sense for a PSTN gateway to communicate
these properties, but probably for few other UACs to do so. Of course,
caller preference attributes of various kinds could be added by such
intermediaries, but it isn't immediately clear to me that this is in keeping
with the spirit of caller prefs (which exists to allow user agents to
specify preferences in order to reduce the amount of policy that must be
configured in the network - having intermediaries add these preferences to
requests and responses seems to kind of defeat the whole purpose).

Introducing some 'cpc=' tel URL parameter that would appear in the Contact
header of SIP requests could be syntactically very similar to introducing
corresponding caller preferences values that would appear in the Contact
header of SIP requests (though the 'cpc=' tel URL parameters would appear in
the user portion of the SIP URI in the Contact header). The big difference
is in how feature sets are processed by caller preferences, and the
pre-existence of a system by which callees can easily express their
preferences upon registration - rather than local policy dictating how a
particular calling party's category is handled, instructions from user
agents would guide the behavior of intermediaries. In the traditional PSTN
view, of course, the intermediaries that would ordinarily consume CPC
information would be driven exclusively by local policy.

The former model is more suitable to a greenfield SIP network, and the
latter model is more desirable if you want to run a network that uses these
parameters as the PSTN intended - usually, given that choice, we go with the
former. The issue is really the degree to which the categories and
capabilities identified by the CPC/OLI parameters are applicable to an IP
environment and security model. If no SIP user would ever care to register
preferences related to any of the multitude of values associated with the
CPC (how would a user know whether or not they want to receive calls from
"operators with forward facility") - and to do so in a way that would be
interoperable with the values generated by gateways - then I'm not sure
caller preferences is the right way to do it. If CPC/OLI values are only
really relevant to URIs that are telephone numbers, then that argues that it
could be coupled with the tel URL - the CPC parameter might even be relevant
to applications other than SIP that express telephones numbers with URLs.
I'd also note that creating a bucket tel URL parameter like 'cpc=' and
giving it an IANA registry seems like it would require less standardization
work than corresponding all of the possible CPC values to caller
preferences. 

Finally, speaking to Jonathan's point below, I think that the use of a URI
to specify the originator of a request in SIP is different in a few
fundamental ways from how the originator of a call is specified in the PSTN,
and that this creates some tension in SIP-ISUP mapping - the SIP
From/Contact headers essentially just supply a return address, not
additional data about the originator. The URI in a Contact header of a
request that initiates a dialog shouldn't, I agree, contain cruft unrelated
to the routing of new requests in the dialog. Whether or not the category of
the calling party could ever be relevant to that is arguable. Could that
fact that a terminal is a payphone ever serve some function in identifying
the terminal as a resource? I think it could...

I guess I'm on the fence.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, September 12, 2002 1:27 PM
> To: Peterson, Jon
> Cc: 'Henning Schulzrinne'; 'Romel Khan'; [email-masked]
> Subject: Re: [Sipping] Re: [Sip] Originating Line Information
> 
> 
> 
> 
> Peterson, Jon wrote:
>  > Just as an aside on this matter, I think that a telephone number
>  > traditionally does identify a 'jack-in-the-wall' moreso than a person
>  >  answering, and the attributes identified by the Originating Line
>  > Information in particular are attributes of the terminal and not any
>  > individual using the terminal.
> 
> That to me is not an argument that these parameters are part of the URI; 
> it just means that they are fairly static. Anyway I would think number 
> portability would argue that numbers really don't ever identify jacks in 
> the wall any more.
> 
> URIs identify a resource, they don't describe it.
> 
> 
> 
> Staging OLI in the tel URL prevents
>  > this telephony-specific usage from contaminating the SIP 
> URI, perhaps
>  > at the cost of some redundancy with potential usages of 
> caller-prefs.
> 
> I don't see that its desirable to have two ways of doing the 
> same thing.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
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: Tue, 17 Sep 2002 12:49:42 -0400

I don't see this as an either-or proposition. It may be useful to just 
carry the original CPC information as part of the tel URI, to avoid 
information loss if a particular digit combination is not known to the 
gateway and thus can't be translated into something meaningful.

You did not mention a third category (beyond CP and URI parameters) that 
I think is relevant here: informational data contained in the SIP 
request, e.g., as part of a header. For these, it seems perfectly 
appropriate to have them be asserted by some entity other than the 
originator. Indeed, this seems to be very similar to the 
network-asserted identity question and may well fit into the same 
framework, privacy and all. (After all, information as to whether the 
caller is in a motel or prison or, less so, on a payphone can be 
considered to be subject to privacy constraints.)

In general, we may want third parties to be able to provide information 
as a service. For a somewhat far-out example, one could imagine routing 
calls through a BBB-sponsored service that includes the BBB-rating in 
the setup request.

SDP does not have language information, but caller preferences does, for 
exactly the reasons you mention, except that it is not restricted to 
telephone company operators, but could be used to select the appropriate 
in-bound telemarketer position.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Sep 2002 14:46:54 -0400

If gateways are involved it may be useful as has been stated to rely on the 
encapsulated ISUP information, which may have national variant-specific values.

The primary question for me is whether this information would be useful in 
a pure SIP environment without any PSTN involvement.  For that reason, I am 
less favorably disposed to a parameter in a tel: URI which may not be 
appropriate.

As for German versus other operators, breaking down these adjectives into 
component parts would avoid having to list every permutation.  Thus, it is 
the indication of operator, prison, or hotel that is needed, which when 
combined/intersected with the language or other adjectives provides a more 
complete picture.

This would appear to me to be an input to the routing function as this 
could affect how one acts on that particular signaling message.  There are 
route server platforms that use this as a primary input to their logic.

Mike

At 12:49 PM 9/17/2002 -0400, Henning Schulzrinne wrote:
>You did not mention a third category (beyond CP and URI parameters) that I 
>think is relevant here: informational data contained in the SIP request, 
>e.g., as part of a header. For these, it seems perfectly appropriate to 
>have them be asserted by some entity other than the originator. Indeed, 
>this seems to be very similar to the network-asserted identity question 
>and may well fit into the same framework, privacy and all. (After all, 
>information as to whether the caller is in a motel or prison or, less so, 
>on a payphone can be considered to be subject to privacy constraints.)
>
>In general, we may want third parties to be able to provide information as 
>a service. For a somewhat far-out example, one could imagine routing calls 
>through a BBB-sponsored service that includes the BBB-rating in the setup 
>request.
>
>>> > this telephony-specific usage from contaminating the SIP URI, perhaps
>>> > at the cost of some redundancy with potential usages of caller-prefs.
>>>
>>>I don't see that its desirable to have two ways of doing the same thing.
>>>
>>>-Jonathan R.
>>>
>>>-- Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.