Pete,
I would agree with what you are saying here, coming from a public network
background I would agree with your analysis. We seem to be talking about a
number of different identity services which we seem to be mapping onto the
calling party number information element. I think if we are going to include
the octet 3 and octet 3a we should be clear about which service we are
supporting.
Presentation identity services: Used by the terminating end
to return a call or reference a database, this number normally has very slim
requirements for authenticity, and could be any number within the E.164
number range.
Subscriber identification services: Identifies the subscriber, may be
used for malicious call identity services, this number must be authenticated
and is only ever provided by the network.
Location identification services: Identifies the location of
the call, may be used for emergency services in cases, this number must be
authenticated and is also traditionaly provided by the network.
>From what a few others are saying, their requirement would be to support the
first case, presentation identity services. In most cases for communicating
identities between PBXs that have no real need for some form of suscriber
identification or location identification. The security and authentication
tokens which you mention, would definitly be required if an emergency call
is made. This is obviously a big issue and possibly can be dealt with
seperatly from the short term requirements for presentation identity
services.
The policy I think that should be adopted is that if there is any form of
interworking to the SCN then the number that is sent from the VoIP network
in the absence of some form of authentication should be considered 'user
provided not verified'. The Gateway to the SCN should then take the same
action as if it received a call from a PBX it didn't trust and add some form
of other identity, which would be a default marked against the trunk.
To satisfy those people like myself and Pete, where we add octet 3 or octet
3a we should leave a note that says
"this part of the protocol is not equipped for use by emergency services and
malicious call identification and therefor wherever a calling party number
is included it should be considered as user provided not verified and the
indicators marked accordingly"
I will of course leave it up to you how you decide to include octet3a and
octet3.
Cheers
John
> -----Original Message-----
> From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM]
> Sent: 13 May 1999 05:05
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: caller ID and implementer's guide
>
> Paul,
>
> I now understand where you are coming from when you say that the first
> scheme is proprietary.
>
> However, I think it's slightly different because, although someone might
> be
> upset if you sent H.261 data to an H.263 decoder, they are unlikely to sue
> you for disclosing information that has been requested to be kept private,
> as might be the case if the calling party's telephone number is displayed
> when it has been requested not to be. Hence the need for trust, because
> if
> the entity you send the information to does not honour your request, you
> could end up with some very expensive legal fees!
>
> (As a side note, some sort of calling party id is probably required for
> legal reasons, such as tracing emergency calls. Hence remaining private
> by
> not including the calling party id is not an option. I'm not sure if this
> is what we are talking about , but what is really needed is something that
> only lets those that are allowed to know to access the information. The
> case of the switched network is slightly different to that of IP because
> the
> former is essentially a secure network behind a firewall. The Internet
> and
> most other IP networks does not generally mirror this model and so a
> different solution is required. What is probably required is a
> supplementary service that does call tracing using suitable
> cryptographically secure tokens that are known only to those that are
> allowed to do call tracing.)
>
> Pete
>
> =============================================
> Pete Cordell
> pete.cordell(a)btinternet.com
> =============================================
>
> -----Original Message-----
> From: Paul Long <Plong(a)SMITHMICRO.COM>
> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
> Date: 12 May 1999 14:20
> Subject: Re: caller ID and implementer's guide
>
>
> >Pete,
> >
> >Sorry. I did indeed believe that you were saying that a vendor could take
> >ownership of an IE, which would be a proprietary and rather dangerous
> >solution. "We" or "SG16" in place of "you" might have been a better
> choice
> of
> >words. Your first solution is still proprietary, though. Your counter
> argument
> >is weak because one could use it for all otherwise proprietary features,
> e.g.,
> >"only send H.261 on a channel established for H.263 to an entity that you
> >trust to expect this."
> >
> >Paul Long
> >Smith Micro Software, Inc.
> >
> > -----Original Message-----
> > From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM]
> > Sent: Wednesday, May 12, 1999 6:27 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: caller ID and implementer's guide
> >
> > Paul,
> >
> > I disagree that these are proprietary solutions.
> >
> > The first is a matter of policy and so falls into a slightly grey
> >area, but
> > ideally the standard would say something like 'only send
> presentation
> > restricted information to an entity that you trust to honour the
> >request.'
> >
> > The second is definitely NOT an action you could take at a
> proprietary
> >level
> > as the standards body still holds the right to define new IEs.
> Any
> >such
> > action would have to be approved by the standards body. When I
> said
> >'...YOU
> > could take further ownership...', the 'you' was intended to refer
> to
> >SG16.
> >
> > As such a change is small and localised, it would be safe to
> implement
> >it
> > even if it was mentioned only in a determined document (which is
> the
> >way the
> > procedure is supposed to work after all anyway!) which could be
> >achieved at
> > the Chile meeting. A fix in the ASN.1 would have to wait for the
> >decided
> > version as that needs to wait until all such additions are
> present.
> >
> > Pete
> >
> > =============================================
> > Pete Cordell
> > pete.cordell(a)btinternet.com
> > =============================================
> >
> >
