- sg16-avd - lists.packetizer.com

Re: documents for Chile meeting uploaded
by Espen Skjæran (ETO) 14 May '99

14 May '99

Dear Glen, Reviewing the uploaded document (H.225.0 v3), I find something missing from the Monterey meeting: TD-46 "Include endpointIdentifier in SETUP message" The report states this parameter should be included in v3, however, it is not present. It has been included in the latest implementors guide, but is not present in the uploaded draft of H.225.0 Note that as it was determined to be included in the v2 implementors guide, I included the parameter after the latest v2 parameter, that is before "multipleCalls". Note 2 that the report states it should be mandatory in v3. This applies to "semantically" mandatory, not syntactically (still OPTIONAL in ASN.1, as it has no meaning if the call is not gk-routed) APC-1543/TD-23 "Indication of H.323 Annex E capabilities to gatekeeper" APC-1543 seems to have been included in the document, whereas I believe the revised version (TD-23) were the one to be incorporated. I believe the "totalBandwidthRestriction" also should apply for gateways, as it is specified "for all calls", and plays the role of the Bandwidth parameter in ACF which also applies to gateways. However, a gatekeeper setting this parameter should be aware of the gateways' need for more bandwidth in order to increase available bandwidth or abandon the limit for a specified gateway. Regards, Espen -----Original Message----- From: Glen Freundlich [mailto:ggf@lucent.com] Sent: 12. mai 1999 21:22 To: ITU-SG16(a)mailbag.cps.intel.com Subject: documents for Chile meeting uploaded Dear Q.12-14/16 experts, I have placed the following documents in the Incoming directory of the pictel ftp site: h225.zip - draft H.225.0 V3 updated through Monterey meeting H283_changes_TD.doc - editorial changes to the H.283 white draft TD_H243.doc - changes to H.243 Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

2 1

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by Matt Holdrege 14 May '99

14 May '99

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(a)madge.com > > >> -----Original Message----- >> From: Matt Holdrege [mailto:matt@ASCEND.COM] >> Sent: 13 May 1999 6:46 >> To: ITU-SG16(a)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@SMITHMICRO.COM] >> >> Sent: Thursday, May 13, 1999 10:41 AM >> >> To: ITU-SG16(a)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@MADGE.COM] >> >> Sent: Thursday, May 13, 1999 8:28 AM >> >> To: ITU-SG16(a)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(a)madge.com >> >> >> > >> >

1 0

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by Chris Purvis 14 May '99

14 May '99

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(a)madge.com > -----Original Message----- > From: Matt Holdrege [mailto:matt@ASCEND.COM] > Sent: 13 May 1999 6:46 > To: ITU-SG16(a)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@SMITHMICRO.COM] > >> Sent: Thursday, May 13, 1999 10:41 AM > >> To: ITU-SG16(a)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@MADGE.COM] > >> Sent: Thursday, May 13, 1999 8:28 AM > >> To: ITU-SG16(a)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(a)madge.com > >> > > >

1 0

Re: caller ID and implementer's guide
by Paul Long 13 May '99

13 May '99

Chip, Funny you should ask. In my first response to Glen, I said that we clear the call, but just a few minutes ago I took another look at the code and found that we completely ignore the calling party number IE in SETUP. Skip right over the sucker. I must have been looking at how we handle the octet-3 extension bit for another IE, e.g., bearer capability (even Q.931 requires it to always be 1). While it turns out that we accept a call regardless of whether the extension bit under discussion is set, I still stand by my assertion that an EP cannot send a SETUP message to a v1 or v2 EP with the extension bit of octet 3 set to 0 and octet 3a present. I happen to know what my implementation does, and the impact is minimal, but there are bound to be implementations out there that--through no fault of their own--will in effect become "broken" if we decide that this bit can be set to 0 and this octet can be present after all. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Chip Sharp [SMTP:chsharp@CISCO.COM] Sent: Thursday, May 13, 1999 3:49 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide What does your implementation do if it receives a "0" in the Extension field of Octet 3? Chip

1 0

Re: caller ID and implementer's guide
by Paul Long 13 May '99

13 May '99

(Again, apologies if you've already received this. It didn't bounce off the reflector to me either, so I'm sending it again.) Pete, I didn't make myself clear. I wasn't talking about whether someone might be emotionally or "litigiously" upset. My point was that the admittedly silly situation of transmitting H.261 over an H.263 channel clearly violates the Recommendations, regardless of whether I know that the remote entity expects this. Likewise, setting the extension bit of octet 3 in the calling party number IE to 0 and therefore including octet 3a is also a clear violation of H.225.0v1 and v2, regardless of whether the receiving entity expects this non-compliant behavior. There is no way to get around 7.2.2.1's "_shall_ be set to '1'." These are both non-interoperable, proprietary scenarios. Let me say it in yet another way (and yes I am running out of ways to say it): A v1 or v2 EP must set this bit to 1, and no EP, regardless of revision, must ever set it to 0 if the remote EP is v1 or v2. This is not merely my opinion--this is in effect what H.225.0v1 and v2 say. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Pete Cordell [SMTP:pete.cordell@BTINTERNET.COM] <mailto:[SMTP:pete.cordell@BTINTERNET.COM]> Sent: Thursday, May 13, 1999 4:05 AM To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@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 <mailto:pete.cordell@btinternet.com> =============================================

1 0

Re: caller ID and implementer's guide
by Paul Long 13 May '99

13 May '99

(Apologies if you've already received this. It didn't bounce off the reflector to me, so I'm sending it again.) Karl, I agree that adding yet another calling-party-number field is not a good thing, but neither Glen's nor your most recent proposal takes into consideration that the octet-3 extension bit "_shall_ be set to '1'" at least for v1 and v2. Therefore, octet 3a can never be sent to a v1 or v2 EP. Any solution will have to take this into account. Mine does. There may be others. One could clarify perhaps ambiguous parts of a revision, but you can't go back and fundamentally change the rules simply by adding words to the Implementers Guide. Compliant products are already shipping that do not expect octet 3a to be present, because the Recommendation says that it can't be present. To change the rules at this point would at the very minimum be quite unfair. Note: I'm not real familiar with the ITU standards-making process, but I don't think that agreement at the SG meeting in Monterey even constitutes Determination. These SG meetings are part of the iterative refinement of a draft Recommendation before submitting it to the Working Party. Although maybe not officially part of the ITU standards-making process, this email reflector is vital in exposing the process to a wider audience than those that attended the meetings. Besides, even if Decided for H.225.0v3, Glen's proposed "fix" can only be applied between v3 EPs, so a v3 EP employing it would have to determine the version of the remote EP before it sent SETUP (which would be quite a trick). If the remote is v1 or v2, it can't set the extension bit of octet 3 in the calling party number IE to 0. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Karl.Klaghofer(a)ICN.SIEMENS.DE <mailto:Karl.Klaghofer@ICN.SIEMENS.DE> [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] <mailto:[SMTP:Karl.Klaghofer@ICN.SIEMENS.DE]> Sent: Wednesday, May 12, 1999 4:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> Subject: AW: caller ID and implementer's guide Paul, We have already two elements in H.225.0 that carry Calling party number information: - Calling Party Number Information Element, and - sourceAddress in Setup-UUIE. I would prefer a solution that avoids introducing a third element. You have agreed that an "comliant" EP that receives an octet 3a in Calling party number from a "non-compliant" EP shall: - ignore the complete information element - shall process the rest of the message - shall not clear the call - optionally send STATUS (which we might exclude, due to the argument mentioned by Chris Sharp) Based on these rules, I have derived a procedure that allows exceptional CLIR Interworking support in H.225.0v2(v1), which should go to the implementors guide. How about this ? ( Note: I understand that for H.323v3 (H.225.0v3) the proposal as presented by Glen Freundlich in Monetrey was accepted). " Exceptional procedures for H.225.0v2(v1) Interworking with SCN CLIR "Calling Line Identification Restriction" feature: 1) Sending of Calling Party Number Information Element with CLIR information: In order to enable interworking with the SCN Calling Line Identification Restriction (CLIR) feature, an endpoint (e.g. terminal or incoming gateway) may include an octet 3a containing "Presentation Indicator" and "Screening Indicator" fields, but only if presentation at the destination is to be restricted. The presentation Indicator field in this case shall be set to "01" (Presentation restricted). If octet 3a is included, the extension bit in octet 3 bit 8 shall be set to "0". For the coding of Calling Party Number IE octet 3a refer also to Q.931 clause 4.5.10. The sourceAddress field should not be present. If presentation is to be allowed, octet 3a shall NOT be included in the Calling Party Number Information Element. 2) Receiving Calling Party Number IE including CLIR information: An EP that receives a Calling Party Number Information element including octet 3a with "presentation restriction" shall act as follows: 2a) If the EP supports the CLIR extensions as defined in 1) above, it shall NOT display the Calling Party Number to the user (the Calling party Number may be stored and e.g. used inconjunction with supplementary services). Additional identification information received within sourceAddress in Setup-UUIE shall NOT be displayed to the user as well. If the called endpoint is not trusted, the gatekeeper may remove a Calling Party Number IE containing CLIR indication before passing the SETUP message to the called endpoint. 2b) An EP that does not support the exceptional procedure for CLIR support as mentioned in 1) above, which receives a Calling Party Number Information Element with octet 3 bit 8 NOT set to "1" but set to "0" (i.e. octet 3a present) shall: - ignore the complete Calling Party Number Information element and - process the rest of the SETUP message (i.e. this "optional information element content error" shall not lead to call clearing). - A STATUS message (as recommended in Q.931 for such a situation) should not be sent. " Regards, Karl

2 1

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by Tom-PT Taylor 13 May '99

13 May '99

Agreed. > -----Original Message----- > From: Matt Holdrege [SMTP:matt@ascend.com] > Sent: Thursday, May 13, 1999 1:46 PM > To: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Cc: ITU-SG16(a)mailbag.cps.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@SMITHMICRO.COM] > >> Sent: Thursday, May 13, 1999 10:41 AM > >> To: ITU-SG16(a)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@MADGE.COM] > >> Sent: Thursday, May 13, 1999 8:28 AM > >> To: ITU-SG16(a)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(a)madge.com > >> > >

1 0

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by Matt Holdrege 13 May '99

13 May '99

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@SMITHMICRO.COM] >> Sent: Thursday, May 13, 1999 10:41 AM >> To: ITU-SG16(a)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@MADGE.COM] >> Sent: Thursday, May 13, 1999 8:28 AM >> To: ITU-SG16(a)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(a)madge.com >> >

1 0

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by John Talbot 13 May '99

13 May '99

Paul to answer your questions > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: 13 May 1999 10:41 > To: ITU-SG16(a)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, [Talbot, John [MAIFP:EP12:EXCH]] The requirements themselves are defined by government bodies, but allowing the protocol to support these services is definitly a standards related issue since compiance to them is faced by nearly every vendor. > 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 [Talbot, John [MAIFP:EP12:EXCH]] Yes that was the malicious call identity service where if I harass someone using my phone the police can trace who I am. Satisfying these services is traditionaly enshrined in operator licenses. > Caller ID not to be displayed to the called party if so requested by the > caller ("presentation restricted") [Talbot, John [MAIFP:EP12:EXCH]] Again, yes this comes under data protection legislation which is enshrined in the voice telephony guidelines and therefor governs most operators in Europe. I believe though that compliance to this is not so strictly defined in the laws in North America, if I dial a 1800 number, even if I restrict my number that restriction is not honoured. > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > Sent: Thursday, May 13, 1999 8:28 AM > To: ITU-SG16(a)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(a)madge.com >

1 0

Re: Caller ID legal issues (was: caller ID and implementer's guid e)
by Tom-PT Taylor 13 May '99

13 May '99

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@SMITHMICRO.COM] > Sent: Thursday, May 13, 1999 10:41 AM > To: ITU-SG16(a)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@MADGE.COM] > Sent: Thursday, May 13, 1999 8:28 AM > To: ITU-SG16(a)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(a)madge.com >

1 0