- sg16-avd - lists.packetizer.com

Caller ID legal issues (was: caller ID and implementer's guide)
by Paul Long 13 May '99

13 May '99

(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 ("… [View More]

1 0

Re: caller ID and implementer's guide
by John Talbot 13 May '99

13 May '99

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 … [View More]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 > > ============================================= > > > > [View Less]

1 0

Re: caller ID and implementer's guide
by Chris Purvis 13 May '99

13 May '99

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 - … [View More]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: Pete Cordell [mailto:pete.cordell@BTINTERNET.COM] > Sent: 13 May 1999 10: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 > > ============================================= > > > > > [View Less]

1 0

Re: caller ID and implementer's guide
by Pete Cordell 13 May '99

13 May '99

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 … [View More]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 > ============================================= > > [View Less]

1 0

Glen Freundlich's documents
by Sakae OKUBO 12 May '99

12 May '99

Dear Q.12-14/16 experts, The following files have been (renamed and) moved to the /9905_San directory: ftp://standard.pictel.com/avc-site/9905_San/ or http://standard.pictel.com/ftp/avc-site/9905_San/ GF> h225v301.zip - draft H.225.0 V3 updated through Monterey meeting GF> H283_changes_TD.doc - editorial changes to the H.283 white draft GF> TD_H243.doc - changes to H.243 Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research … [View More]

1 0

Annex E Version
by Chip Sharp 12 May '99

12 May '99

What version of Annex E is up for approval in Santiago? The only version on the Pictel site is the white paper from last December. Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------

1 0

[Fwd: Fw: The Pulver Report - May 6, 1999 Issue]
by Edgar Martinez [1] 12 May '99

12 May '99

fyi -------- Original Message -------- Subject: Fw: The Pulver Report - May 6, 1999 Issue Date: Wed, 12 May 1999 15:05:43 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: TIPHON : Entirely <TIPHON(a)LIST.ETSI.FR> References: <199905120306.WAA15708(a)alba.cig.mot.com> Dear All, I know SIP is taboo, in some groups, but we need to confront the possibilities. For information: SIP or not to SIP. Since SIP runs on a IP Network, I think we need … [View More]to consider how to interwork supplementary services between H.323, SIP and WAP/WTA. As part of the TIPHON's Forward looking IP network configurations. Could SIP and WAP/WTA be looked at as (BES) or will it be part of the TIPHON's family of applications. If we took the concept of the SCN where for example: SCN world | IP world --------------------------------- Q.931 call control can = H.323/h.225 Q.932 NCAS/CAS can = (SIP)into H.323/h.450x/h.246 Annex? Same thing applies to SS7 where: SCN | IP world ---------------------------------- ISUP can = H.323/h.246 Annex? TCAP(services) can = (SIP)into H.323/h.450x/h.246 Annex? The services and requirements we are looking to provide in TIPHON. I believe we will need to support both SIP and H.323. Not only in the Gateway decomposition but within the core TIPHON applications. Regards, Ed ---Forwared message--- > Subject: Re: The Pulver Report - May 6, 1999 Issue > > Jeff Pulver wrote: > > THE PULVER REPORT(TM) > > Provided by: pulver.com, Inc. > > The May 6, 1999 Issue: > > ..... > > > ------------------------------------------------------------------- > > SIP is Happening > > A week before Spring '99 VON, the first SIP Bakeoff took place at > Columbia > University. Eighteen engineering groups representing fourteen vendors > and research organizations met to jointly test the operation of their > Internet Telephony SIP products. > > At the end of the event, nearly all of the implementations had achieved > interoperability for call setup and media capability negotiation for > multimedia calls. Several were interoperable on the first try, and most > others after minor changes were made. Systems being tested > included user agents and servers running on a various of operating > systems. The event was able to show subscribers can move from location > to location, (anywhere on the Internet), with phone calls following them > automatically, regardless of the provider of the hardware or software. > Users could also forward calls to any Internet destination or telephone > number. Some groups also tested advanced features such as call > screening and user authentication. > > Organizations participating in the SIP interoperability testing came > from > the US, Canada, Sweden, Finland and the UK and included, among others: > 3Com, Alcatel, Cisco, British Telecom, Columbia University, Dialogic, > dynamicsoft, Ellemtel, Ericsson, Helsinki University of Technology, > Hewlett-Packard, Lucent, Mediatrix, Nortel, and Pingtel. > > > During 1998 the IP Telephony MoU was successful in creating and > contributing > a suggested Call Detail Record (CDR) for the VON Industry. In 1999 our > focus has shifted to contributing a SNMP-2 MIB for the Industry which > reflects the needs of Service Providers. > > As a follow up to a discussion held at the IP Telephony Retreat in > February > and a follow up meeting which was held during Spring '99 VON, the next > MoU-MIB meeting is scheduled to take place May 19-20 at the JFK Airport > Hilton. At this meeting we will be discussing the creation of an IP > Telephony MIB which is designed based on the needs of Service Providers. > > Hans Eriksson of Telia writes: "During the spring Telia has together > with > Clarent, Inter-tel and Nokia gathered a common basic MIB for gateways. > As we are going for a multi-vendor deployment a common MIB is absolutely > crucial for us. The current proposal is a collection of stuff from > existing MIBs (H.341, E1, ISDN, MIB-II, etc) as well as some additions. > This is a very basic first cut that needs to be extended in the near > future. Telia welcomes this initiative to form a MoU-MIB group and will > bring our work and resources to progress this." > > Hans Eriksson from Telia will be at the JFK Meeting and will help lead the > discussions together with Carl Ford and Jeff Pulver. If you are a > service provider or equipment vendor, and if would you would like to > attend this meeting, please email: mib(a)pulver.com or visit: > ( http://pulver.com/mou ) for more information. > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/ [View Less]

1 0

documents for Chile meeting uploaded
by Glen Freundlich 12 May '99

12 May '99

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

1 0

H.245 In the Media Gateway
by Tom-PT Taylor 12 May '99

12 May '99

This note is just a heads-up to prime discussion of one issue related to Gateway decomposition. It is clear that at least under some circumstances (e.g. MCUs), it is highly desirable to co-locate H.245 signalling with the Media Gateway function. This is specifically to take the higher-layer resource control off the critical path for functions such as frame-associated signalling. What I hope we can put together is a clear picture of exactly what has to be sent up to higher-layer resource … [View More]

1 0

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

12 May '99

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 … [View More]

1 0