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

From: Michael Hammer <[email-masked]>
Date: Thu, 12 Sep 2002 15:58:50 -0400

Jon,

Some thoughts as you re-write the draft (I don't recall this one off-hand):

Will you be able to normalize the value set across CPC and OLI?
Will this be usable for more than just the calling party?
    (can nature of a called or redirecting party be indicated?)
Will it be possible to apply more than one value simultaneously?
    (like prison and payphone and emergency)

Mike

At 03:14 PM 9/12/2002 -0400, 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. 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.
>
>Jon Peterson
>NeuStar, Inc.
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Thursday, September 12, 2002 12:02 PM
> > To: Jonathan Rosenberg
> > Cc: Peterson, Jon; 'Romel Khan'; [email-masked]
> > Subject: Re: [Sipping] Re: [Sip] Originating Line Information
> >
> >
> > In general, I think the basic rule should be "if the URI is different,
> > the resource is a different resource". This doesn't have to be true all
> > the time, but the URI is after all an *identifier*, not a description.
> > The URI should also be somewhat permanent and publishable.
> >
> > At least for the prison or motel phone, these are hopefully temporary
> > conditions, unless the URI identifies the jack-in-the-wall rather than
> > the person answering.
> >
> > Jonathan Rosenberg wrote:
> > > Moving to sipping.
> > >
> > > Another option is caller preferences. We could register
> > parameters for
> > > these various things, which would allow you to do things like:
> > >
> > > INVITE
> > > Contact:
> > <sip:1.2.3.4>;prison="TRUE";methods="INVITE,BYE,BLOWUPMYPHONE"
> > >
> > > and so on.
> > >
> > > This leads to a question we haven't really discussed in too
> > much depth
> > > yet - when does descriptive information belong as a tel/SIP URI
> > > parameter, and when does it belong as a caller prefs
> > contact parameter?
> > >
> > > My general take on this is that things which describe
> > characteristics of
> > > a URI - such as the MIME type of the document being
> > referenced, or the
> > > color of the phone it desribes, are not part of the URI,
> > but belong in
> > > the realm of things like caller prefs which desribe URIs.
> > The URI, IMHO,
> > > should contain the minimal amount of stuff.
> > >
> > > -Jonathan R.
> > >
> > > Peterson, Jon wrote:
> > >
> > >> This is more a SIPPING issue than a SIP issue... but yes,
> > I was hoping
> > >> that
> > >> my proposal for a calling party's category tel URL parameter cover
> > >> this (it
> > >> speaks to the fact that in North American networks, the
> > OLI is often the
> > >> repository for information that appears in the CPC
> > elsewhere). The draft
> > >> happens to be expired at the moment, though I will be
> > resubmitting it
> > >> fairly
> > >> soon.
> > >>
> > >> Jon Peterson
> > >> NeuStar, Inc.
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Romel Khan [mailto:[email-masked]]
> > >>> Sent: Wednesday, September 11, 2002 2:47 PM
> > >>> To: [email-masked]'
> > >>> Subject: [Sip] Originating Line Information
> > >>>
> > >>>
> > >>> Is there any existing internet draft that talks about how to pass
> > >>> Originating Line Information (e.g. hotel, motel, prison) in SIP?
> > >>> _______________________________________________
> > >>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >>> This list is for NEW development of the core SIP Protocol
> > >>> Use [email-masked] for questions on current sip
> > >>> Use [email-masked] for new developments on the
> > application of sip
> > >>>
> > >>
> > >> _______________________________________________
> > >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >> This list is for NEW development of the core SIP Protocol
> > >> Use [email-masked] for questions on current sip
> > >> Use [email-masked] for new developments on the application of 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

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 13 Sep 2002 07:04:05 +0200

Hi Mike,
within ISUP the CPC is only used once. In some countries there are national CPC that could be set additionally or instead of the CPC.

I have a question regarding the OLI is it the same as an Generic number (ACgPN)?

For the  Redirecting Party there is a own Parameter within ISUP/BICC that is called redirecting number but there are some parameters more that are used for redirection like call diversion information, Redirecting information....I think that's about 10 Parameters for international and/or national use.

But if you like to have the complete picture you should read the Q.761-764 and 1902.X and of course the service descriptions regarding Call diversion.

Roland

-----Ursprungliche Nachricht-----
Von: Michael Hammer [mailto:[email-masked]]
Gesendet: Donnerstag, 12. September 2002 14:59
An: Peterson, Jon
Cc: 'Henning Schulzrinne'; Jonathan Rosenberg; 'Romel Khan';
[email-masked]
Betreff: RE: [Sipping] Re: [Sip] Originating Line Information

Jon,

Mike

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 16 Sep 2002 15:22:04 +0200

The question is for what do you want to use SIP. If you like to use it for the public internet then you have no problems to keep your user to user focus as it is already specified.
But if you like to migrate public telephony networks using ISUP to SIP then you have to keep all the security and regulation issues in mind and then you need such kind of information like the CPC, P-Asserted-ID and others.
From the operator point of view if this information is within the URI or a CPC-header, doesn't care because the interworking function must analyse the full SIP message.

Best Regards

Roland

Deutsche Telekom AG
T Com Zentrale
Section T38; Signalling, Gateways and Switching Systems 
Roland Jesske, T38a12
Am Kavalleriesand 3, 64295 Darmstadt, Germany
Phone:  +49 6151 83-5940 
Fax:    +49 6151 83-4577 
mailto: [email-masked] <mailto:[email-masked]> 

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Montag, 16. September 2002 14:38
> An: Henning Schulzrinne
> Cc: Michael Hammer; Jesske, Roland; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [Sipping] Re: [Sip] Originating Line Information
> 
> 
> 
> 
> 
> With this sort of discussion, isn't there a danger that SIP 
> will evolve
> into a newer version of ISUP? What should be in a base SIP 
> specification
> and what should be left as extensions for the various application
> architectures that will utilise SIP?
> 
> Tom Gray
> 
> 
> 
> 
> 
> 
> Henning Schulzrinne <[email-masked]>@ietf.org on 
> 09/13/2002 01:18:59
> PM
> 
> Sent by:  [email-masked]
> 
> 
> To:   Michael Hammer <[email-masked]>
> cc:   "Jesske, R" <[email-masked]>, [email-masked],
>       [email-masked], [email-masked], [email-masked]
> Subject:  Re: AW: [Sipping] Re: [Sip] Originating Line Information
> 
> 
> This seems like another version of the *-Info header field, as it
> describes a particular request.
> 
> Michael Hammer wrote:
> > Roland,
> >
> > I understand that today a single CPC is used.  Just 
> wondered if it is
> > worth exploring whether multiple values may allow richer 
> functionality
> > and decision-making to occur.
> >
> > Generic Address is the same as Generic Number.  The OLI is the ANI
> > information digits (II).  Below is a list of the types of 
> values that
> > may need coverage.
> >
> > The CPC is in addition to the identification of the party 
> as calling,
> > called, or redirected, which already has expression as SIP 
> headers.  I
> > don't know that it is necessary to have separate sets
> > (headers/parameters/fields) of values depending on whether it is
> > original calling, calling, called, redirecting, or some 
> other party that
> > the call touched at some point.  One data set of labels of 
> the CPC type
> > may be sufficient.
> >
> > Calling Party Category values in various standards:
> >      00 - unknown
> >      01 - operator, Language French
> >      02 - operator, Language English
> >      03 - operator, Language German
> >      04 - operator, Language Russian
> >      05 - operator, Language Spanish
> >      06 - admin1
> >      07 - admin2
> >      08 - admin3
> >      09 - ordinary calling subscriber
> >      10 - ordinary calling subscriber with customer meter
> >      11 - calling subscriber with priority
> >      12 - data call (voice band data)
> >      13 - test call
> >      14 - customer payphone
> >      15 - public   payphone
> >      16 - emergency service call
> >      17 - high priority emergency service call
> >      18 - national security and emergency preparedness (NS/EP call)
> >      19 - trunk offering
> >      20 - mobile customer
> >      21 - PBX subscriber
> >      22 - operator with forward facility
> >      23 - intercept operator
> >      24 - cross-border operator
> >      25 - long distance payphone
> >      26 - international payphone
> >      27 - international test equipment
> >      28 - check calling party number
> >      29 - national operator
> >
> > BCI has a Called Party Category
> >      0 - no indication
> >      o - ordinary
> >      p - payphone
> >
> > Originating Line Information
> >      00 - pots
> >      01 - multiparty line
> >      02 - ANI failure
> >      06 - Station Level Rating
> >      07 - special operator handling required
> >      08 - inter-LATA restricted
> >      10 - test call
> >      20 - AIOD-listed DN sent
> >      23 - coin or non-coin on calls using database access
> >      24 - 800 service call
> >      25 - 800 service call from a pay station
> >      27 - payphone using coin control signaling
> >      29 - prison/inmate service
> >      30 - intercept (blank)
> >      31 - intercept (trouble)
> >      32 - intercept (regular)
> >      34 - telco operator handled call
> >      36 - CPE
> >      52 - OUTWATS
> >      60 - TRS call from unrestricted line
> >      61 - wireless/cellular PCS (type 1)
> >      62 - wireless/cellular PCS (type 2)
> >      63 - wireless/cellular PCS (roaming)
> >      66 - TRS call from hotel
> >      67 - TRS call from restricted line
> >      68 - inter-LATA restricted hotel
> >      78 - inter-LATA restricted coin-less
> >      70 - private pay-stations
> >      93 - private virtual network
> >
> > Also, Opt. BCI also includes an indication of MLPP user.  
> There may be
> > other fields I overlooked.
> >
> > Mike
>

---

From: [email-masked]
Date: Mon, 16 Sep 2002 10:21:29 -0400

To maintain a necessary degree of separation between base SIP and a needed
SIP-ISUP interworking system, would the idea of a separate working group (a
la SIMPLE) be something worth considering?

Henning Schulzrinne <[email-masked]>@ietf.org on 09/16/2002 08:57:30
AM

To:   [email-masked]
cc:   Michael Hammer <[email-masked]>, "Jesske, R"
      <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  Re: AW: [Sipping] Re: [Sip] Originating Line Information

That's why I was trying to abstract the problem. So, rather than
creating a direct mapping from ISUP CPC to some SIP element, I'd prefer
to look at the more generic question of how to convey properties of the
call and caller. There seem to be at least four approaches:

- The SIP URI in the From field. I believe we agreed that URIs are
*identifiers*, not descriptors, so they should contain only enough
information to uniquely identify the resource. (Unless
[email-masked];type=motel and [email-masked];type=prison are distinct
individuals, rather than the same person before and after the G-men
knocked on the door, this shouldn't be part of the URI.)

- Caller preferences. Advantage is that this can be part of the
registration, can be used in call routing and we already have means to
test for this in CPL scripts.

- Some kind of *-Info header. Seems mostly useful for values, such as
URIs, rather than flags.

[email-masked] wrote:
>
>
> With this sort of discussion, isn't there a danger that SIP will evolve
> into a newer version of ISUP? What should be in a base SIP specification

---

From: Michael Hammer <[email-masked]>
Date: Mon, 16 Sep 2002 11:52:56 -0400

Roland,

It is understood how CPC is used today.  The question is whether, in an 
end-to-end system, where the origination point provides the services and 
makes subsequent routing decisions based on feedback from a called or 
referred-to party, whether some additional characterization of the parties 
would be useful input to the decision-making process of the originator?

Mike

At 08:18 AM 9/16/2002 +0200, Jesske, R wrote:
>Hi Mike,
>the CPC is used as an routing relevant parameter and is also 
>charging/accounting relevant. If you put two CPC in an AIM message the 
>switch doesn't know on which CPC the routing should be done.
>
>For using the CPC twice you need an kind of additional CPC but that isn't 
>standardised within ITU.
>
>The CPC (Q.763) is only used to identify the category of the Calling Party 
>Number and it is only used within the IAM (mandatory) and the national 
>used parameters Information Request and Information. Of course you could 
>extend it within SIP (but there will be no mapping to ISUP), and use it 
>for other numbers like the Redirecting or Original Called PN...but the 
>question is for what do you need it, for which kind of services? But you 
>cannot use it with the Called PN.
>
>It is interesting how ANSI has extended the categories. But if the whole 
>ANSI set is mapped it to SIP what is with the other national variants of 
>the CPC? For that kind of purpose you need an additional field that 
>indicates the ISUP (or "SIP") version where the CPC comes from.
>
>Roland
>
>
>Deutsche Telekom AG
>T Com Zentrale
> > Gesendet: Freitag, 13. September 2002 17:56
> > An: Jesske, Roland
> > Cc: [email-masked]; [email-masked];
> > I understand that today a single CPC is used.  Just wondered
> > if it is worth
> > exploring whether multiple values may allow richer functionality and
> > decision-making to occur.
> >
> > values that may
> > need coverage.
> > The CPC is in addition to the identification of the party as calling,
> > (headers/parameters/fields) of values depending on whether it
> > is original
> > calling, calling, called, redirecting, or some other party
> > that the call
> > touched at some point.  One data set of labels of the CPC type may be
> > sufficient.
> >

---

From: [email-masked]
Date: Mon, 16 Sep 2002 15:48:21 -0400

The major thing about this is that it has implications that go far beyond
ISUP  interworking. I agree with what I think Henning Schulzrinne
suggested. There is an abstract application here for the presentation of
exogenous factors that affect call handling. ISUP interworking is a special
case of this but emphatically  at least from my point of view not a
controlling case by any means.

Tom Gray

Michael Hammer <[email-masked]> on 09/16/2002 11:20:41 AM

To:   <[email-masked]>
cc:   [email-masked], Henning Schulzrinne <[email-masked]>,
      "Jesske, R" <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  Re: AW: [Sipping] Re: [Sip] Originating Line Information

Heaven forbid that past experience should guide us.

Even in an end-to-end model, I would still like to know if a call is coming
from a prison.  It would be even better if it were regulated to be tagged
as "telemarketer" so I could filter that out!  :)

Mike

At 04:17 PM 9/16/2002 +0300, [email-masked] wrote:
>[email-masked] writes:
>
>  > into a newer version of ISUP?
>
>tom,
>
>we have already lost the battle.  sip has already evolved with the
>blessing of ietf into a building block (brick) of a new version of the
>closed mobile network.
>
>-- juha

---

From: [email-masked]
Date: Tue, 17 Sep 2002 15:38:09 EDT

In a message dated 9/17/2002 3:42:47 AM Eastern Standard Time, 
[email-masked] writes:

>
> It is interesting how ANSI has extended the categories. But if the
> whole ANSI set is mapped it to SIP what is with the other national
> variants of the CPC? For that kind of purpose you need an additional
> field that indicates the ISUP (or "SIP") version where the CPC comes
> from.

No way.

We are not doing national variants in SIP.

[MAP] I didn't understand the comment to be that a national variant of SIP 
should be defined, but that a parameter be defined that allows an 
identifcation of which national variant of the CPC is included. In fact, this 
sounds similar to the approach proposed for the Resource-Priority header, 
which would allow a national "namespace" to be identified. We have to avoid 
mapping the ANSI (US) set to SIP without allowing for the corresponding sets 
from other countries.

MIke Pierce
Artel