Caller ID legal issues (was: caller ID and implementer's guid e)

Matt Holdrege matt at ASCEND.COM
Fri May 14 09:51:44 EDT 1999


Perhaps I wasn't clear. As I said, we must be able to transport this
information. For instance, the caller-id information must be able to be
transported to the edge of the network if required. Even if the caller-id
presentation restriction is present. Maybe in a real network the
requirement will be to NOT transport it. That is up to the carrier. Not us.


At 10:33 AM 5/14/99 +0100, Chris Purvis wrote:
>Matt,
>
>With respect, what implementations do IS our business - at least to the
>extent of ensuring that it should be clear from the standard how to
>implement something that is both sensible and compliant.  Several problems
>in the implementation of standards (and, worse, inoperabilities between
>implementations of the standards) have arisen from contributors to standards
>bodies NOT considering implementation.
>
>Regards,
>Chris
>--
>Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
>Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.  ENGLAND
>Phone: +44 1753 661 359  email: cpurvis at madge.com
>
>
>> -----Original Message-----
>> From: Matt Holdrege [mailto:matt at ASCEND.COM]
>> Sent: 13 May 1999 6:46
>> To: ITU-SG16 at MAILBAG.INTEL.COM
>> Subject: Re: Caller ID legal issues (was: caller ID and implementer's
>> guid e)
>>
>>
>> All this means is that the protocol must allow flexibility.
>> For example, it
>> must be able to transport the caller-id presentation restriction and
>> caller-id screening indicator. What the implementations do
>> with that is not
>> our business.
>>
>>
>> At 01:02 PM 5/13/99 -0400, Tom-PT Taylor wrote:
>> >I'm not sure about the first, except that many jurisdictions
>> require support
>> >of emergency services such (e.g. 911 in North America).  There are
>> >definitely regulatory jurisdictions requiring "presentation
>> restricted".
>> >
>> >> -----Original Message-----
>> >> From: Paul Long [SMTP:Plong at SMITHMICRO.COM]
>> >> Sent: Thursday, May 13, 1999 10:41 AM
>> >> To:   ITU-SG16 at MAILBAG.INTEL.COM
>> >> Subject:      Caller ID legal issues (was: caller ID and
>> implementer's
>> >> guide)
>> >>
>> >> (I am straying from the original topic, so I changed the Subject.)
>> >>
>> >> This is not a standards-related issue, so we can end this thread if
>> >> someone
>> >> objects, but I was wondering about the legal ramifications
>> of caller ID.
>> >> Are
>> >> there laws in some countries that require the following,
>> or is it just
>> >> considered good etiquette and/or a market-driven feature?
>> >>
>> >> Caller ID to be transmitted if provided by the caller
>> >>
>> >> Caller ID not to be displayed to the called party if so
>> requested by the
>> >> caller ("presentation restricted")
>> >>
>> >> Paul Long
>> >> Smith Micro Software, Inc.
>> >>
>> >>         -----Original Message-----
>> >>         From:   Chris Purvis [SMTP:Chris.Purvis at MADGE.COM]
>> >>         Sent:   Thursday, May 13, 1999 8:28 AM
>> >>         To:     ITU-SG16 at MAILBAG.INTEL.COM
>> >>         Subject:        Re: caller ID and implementer's guide
>> >>
>> >>         Pete,
>> >>
>> >>         Just a note about the security matter you mention.
>> >>         Some PC based H.323 endpoints allow one, with just a little
>> >> knowledge,
>> >> to
>> >>         persuade them to output debugging which includes
>> all elements of
>> >> decoded
>> >>         RAS/Q.931-H.225.0/H.245 messages.  This is clearly
>> "undesirable"
>> >> when
>> >>         security of information contained in such messages
>> is required!
>> >> It
>> >> also
>> >>         might be quite hard for some people to switch off.
>> >>         I don't have a solution to this: I just raise it
>> as an issue.
>> >>
>> >>         Regards,
>> >>         Chris
>> >>         --
>> >>         Dr Chris Purvis - Senior Development Engineer,
>> WAVE CC Software
>> >>         Madge Networks Ltd, Wexham Springs, Framewood
>> Road, Wexham, Berks.
>> >> ENGLAND
>> >>         Phone: +44 1753 661 359  email: cpurvis at madge.com
>> >>
>> >
>>
>



More information about the sg16-avd mailing list