- sg16-avd - lists.packetizer.com

None
by Delphi 07 Dec '00

07 Dec '00

INFO

1 0

None
by Delphi 07 Dec '00

07 Dec '00

help

1 0

V4 Facility Message
by Paul E. Jones 07 Dec '00

07 Dec '00

Folks, In the Facility message of H.225.0v4, the fields "destinationInfo" and "h245SecurityMode" were added to the Facility message to help routed Gatekeepers cope with the Call Proceeding message. Unfortunately, a routed Gatekeeper cannot use tunnel this put that information into those fields if the endpoint on the other end is V3 or lower. So, we need to clarify this. Francois, you've probably got an idea or two. Should we clarify H.323 someplace to give warning or add something in H.225.0 field definitions? What would you propose we add? Thanks, Paul

1 0

CFP IPtel'2001 Workshop: Extended deadline
by Henning Schulzrinne 06 Dec '00

06 Dec '00

Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due February 10th, 2001 Notification of acceptance March 15th, 2001 Final version due March 25th, 2001 Program published and March 15th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research D. Medhi University of Missouri-Kansas City D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001(a)egroups.com. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Draft Megaco Agenda
by Tom-PT Taylor 04 Dec '00

04 Dec '00

Megaco is meeting on Wednesday morning from 9:00 to 11:30. Here is the proposed Megaco agenda. The primary intention of the meeting is to get a quick sense of the readiness of each I-D for the next step in the process. Given that we are running out of charter, we will not be adding WG work items. The possible dispositions are therefore limited to: (a) No interest (b) More work needed (c) Ready for list last call (d) Forward to IESG as Informational (e) Forward to IESG as potential Standards Track For packages, presentations should show the following: (1) Package summary: name, one-line description, list of properties, events, signals, and statistics defined. (2) Recent updates and any open issues. If you're not presenting your package, let me know ASAP and I will do it. Draft Agenda 1. Agenda Bashing (2 minutes) 2. ITU-T SG 16 Status Tom Taylor (5 minutes) 3. Completion of charter items (a) MIB (draft-ietf-megaco-mib-01.txt) Matt Holdrege (20 minutes) (b) NAS package (draft-ietf-megaco-naspkg-02.txt) Tom Taylor (3 minutes) 4. Well-aged package proposals (a) draft-boyle-megaco-tonepkgs-01.txt (b) draft-boyle-megaco-alerting-00.txt Kevin Boyle (5 minutes) (c) draft-cornel-megaco-enhancedd-00.txt Sarah Cornel (3 minutes) (d) draft-scoggins-megaco-pktnetpkg-00.txt Sophia Scoggins (3 minutes) Contingency: 10 minutes 5. ISDN -- draft-bouwen-megaco-isdn-bcp-00.txt -- draft-bouwen-megaco-isdn-data-00.txt -- draft-bouwen-megaco-isdn-pack-00.txt Jan Bouwen (15 minutes) 6. Other Proposals (a) draft-rosen-megaco-namepatterns-00.txt Brian Rosen (10 minutes) (b) draft-cutler-megaco-recvpkg-01.txt Wayne Cutler (10 minutes) (c) draft-levy-megaco-mgdiscovery-01.txt Thomas Levy (10 minutes) Contingency: 15 minutes 7. Issues From The List Tom Taylor (15 minutes) 8. Interop Reference draft-rosen-megaco-test-profile-00.txt and draft-rosen-megaco-interop-1-report-00.txt Brian Rosen (10 minutes) Hope I've covered everything that's current. Tom Taylor +1 613 736 0961 taylor(a)nortelnetworks.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Registration Of Megaco/H.248 Packages
by Tom-PT Taylor 04 Dec '00

04 Dec '00

In the Megaco/H.248 package registry at http://www.isi.edu/in-notes/iana/assignments/megaco-h248 <http://www.isi.edu/in-notes/iana/assignments/megaco-h248> , the packages marked "IP 11/00" are now "Final". I will have a few new packages for you shortly. Thanks a lot. Tom Taylor taylor(a)nortelnetworks.com <mailto:taylor@nortelnetworks.com> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 04 Dec '00

04 Dec '00

Chris, RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 12:49 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, > The answer to your first question depends on the capabilities of D. > RAS is OPTIONAL so I could have a D device that does not implement RAS. > In my last email, the "third-party" would be a C device and "first-party" > would be a D device (second-party is the A device) . RUBBISH! RAS is NOT optional. See Table 18/H.225.0. Besides, how would your crippled H.323 endpoint tell its RAS handler to send the various RAS messages (like for instance ARQ to ask permission to make a call...)? Regards, Chris > > Regards, > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 10:43 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > In your definition of "third-party" registration, consider a scenario > involving > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > gateway/IWF/registering-entity (C) and an entity of some sort on whose > behalf C > is registering (which we'll call D). Assuming that B is not routing > call-signalling, to which entity would A send its "Setup" message in order > to > contact D? > > If the answer to this question is "C", this is well-covered in the standard > - > it is simply that the term "third-party registration" is not used for it. > It > is simply viewed as C registering (potentially) lots of aliases. This > parallels Tom's second case. > If the answer is "D" (parallelling Tom's first case), then D is a very odd > device (it can't be a full H.323 implementation or it would register for > itself). Why have a device implementing all of H.323 except gatekeeper > registration? After all, D would have to handle all the rest of RAS for > itself > - what would it be gaining by not registering on its own behalf? > > In the same scenario, to what entities are you referring, respectively, as > the > "third-party" in your latest contribution? > > PLEASE clarify your definitions of "first-party" and "third-party" in cases > where you use these terms. I am certain that the ends you are trying to > achieve are perfectly possible - and not even that hard. Either will > result, I > believe, in a brief discussion with early consensus emerging. I believe the > problems, and the large amount of mail this is generating on this list, come > about entirely from the use of these terms without anyone understanding > exactly > what is meant by them. > > I agree with Tom that once we can agree on terminology we can move on quite > easily, and thank him for his usual high-quality clear-sighted input. > > Regards, > Chris > > ------------------------------------ > > The registration feature allows endpoints to bind their identities to > transport > address(es) at the GK. This is well described in H.323. When an endpoint > delegates another endpoint to perform this fearture on its behalf the > definition in H.323 is not there. The signaling that follows the > registration > whether, its > first or third-party may interrogate this binding. The third-party > registration feature can enhance the user experience much more than a normal > first-party > registration. I don't believe that the third-party has to be in the > signaling > flow that may follow the third-registration. I agree with Tom-PTs view. > > Best regards, > > charles > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Wednesday, November 29, 2000 7:39 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Accurate terminology is obviously useful, but in this case, at least, it > looks like something people can agree on and then move on. The more > important point seems to be the underlying distinction in requirements: > > -- register on behalf of H.323 endpoints > -- register on behalf of other endpoints > where I use "other" in the sense that the contact address is associated > with a non-H.323 signalling protocol. Purity is beside the point here -- > it's the intention of the contact address that matters. Stating the > requirement in this way makes it obvious that the second requirement > includes > the need to state which protocol the endpoints expects to receive. > > There is another possibility, of course: use the same mechanism to > satisfy > all requirements, and allow for the possibility that the endpoint > supports multiple protocols. I think the design would be cleaner if we > took the approach: one contact point, one protocol -- even if it meant > repeating the contact information for each protocol a multiprotocol > endpoint supports. > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 12

RFC 3015
by Tom-PT Taylor 04 Dec '00

04 Dec '00

At least on the web interface (the only way I seem to be able to get to look at Megaco correspondence these days), the announce of publication of RFC 3015 seemed to be garbled. RFC 3015 reproduces the content of H.248 as decided last June. It obsoletes the combination of RFCs 2885 and 2886, but does not change what was specified by the combination of those two documents. May we find a less process-ridden way to put out any updates to the protocol! Tom Taylor +1 613 736 0961 taylor(a)nortelnetworks.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: Draft Status Update
by Agboh, Charles 04 Dec '00

04 Dec '00

Paul, Thanks for your comments. I will work on the contribution. Best regards, charles -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, December 03, 2000 11:45 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Draft Status Update Charles, I see us going in one of two directions: 1) Overloading the "h323" field to really be "ipgw", which can reach any protocol 2) Adding new code points for each protocol (one for SIP, one for BICC, etc.) I don't think it's really necessary to create some type of structure that then contains values inside. SupportedProtocols is a CHOICE type, so adding new choices is not expensive in terms of processing or encoding. Also, I suspect we will not be extending this list very many times. SIP and BICC are the only two candidates that I expect we'll be considering in the next few years. It will be small, in any case. What I think you should do is submit a contribution to the next meeting (March 5-9) with the proposal for adding this new field. If you can't attend the meeting, I'll be happy to present the document for you. Paul ----- Original Message ----- From: "Agboh, Charles" <Charles.Agboh(a)gts.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)mailbag.cps.intel.com> Cc: <sip-h323(a)egroups.com> Sent: Sunday, December 03, 2000 10:28 AM Subject: RE: Draft Status Update > I inadvertently sent an incomplete version of this e-mail to the itu-sg16 > mailing list, for that, I appologize. > > > Paul, Bob; > > The SIP-H.323 gateway will be a gateway with multimedia capabilities. The > focus now will be on voice and video. It is possible that other IP > Telephony signaling protocols may be invented in the future and these may > ask for codepoints in H.323. "ipgw" may be a way to provide a codepoint for > the class of IP Telephony protocols. I am wondering what sort of > information should be conveyed in such a structure (apart from the obvious): > ipgw = seqence of { > -protocol id ('sip', 'bicc',...) of type text string > -.... > }. > > > Concering the current verison of the SIP-H.323 gw I(we) agree that "h323" > should be used for now. > > Regards, > > charles > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Friday, December 01, 2000 8:30 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Draft Status Update > > > Bob, > > I suppose it could, though I have not heard anybody focusing on multimedia > in SIP. There are certainly a lot of missing pieces on that side for doing > that. They could do audio and video at the very least. > > The folks I have heard from have been asking for a codepoint to advertise > that the gateway is an H.323 to SIP gateway. The question is simply how to > signal that? There's plenty of options, but we should select the one that > makes the most sense. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, December 01, 2000 3:49 AM > Subject: RE: Draft Status Update > > > > Paul, > > > > Actually a gateway should advertise "voice" if it only support voice. > > Advertising "h323" means that the full multimedia suite of H.323 is > > supported. What is the intent of the H.323 to SIP gateway? Will it > > interwork the full multimedia suite? > > > > Bob > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Thursday, November 30, 2000 6:33 PM > > To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Draft Status Update > > > > > > Bob, > > > > The very fact that SIP is sitting on the back side of this H.323 device > was > > one reason I never pursued trying to add a "sip" codepoint, per se. > Adding > > "sip" as a codepoint might suggest that the SIP devices are doing RAS and > I > > know that would send shivers through the SIP community :-) > > > > Perhaps the right approach is to say that "h323" is the right choice and > we > > should clarify in H.225.0 that this codepoint is used to indicate an H.323 > > GW that reaches other IP-based protocols. > > > > I think we need to say something, because this issue comes up from time to > > time. People want to feel comfortable that when they register a gateway > and > > provide SIP interworking that they advertise the right protocol to the GK. > > I don't see any reason why the GK should care whether the GW is actually > > using SIP, BICC, or H.323 on the back side. > > > > Is there a technical reason why should or should not allow "h323" to be > used > > as I suggest above? I think we're in agreement that this does, indeed, > act > > like nothing more than an H.323 firewall and if it advertises the ability > to > > reach the desired destination-- I suppose that's all we need to care > about. > > > > Paul > > > > ----- Original Message ----- > > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; > > <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Thursday, November 30, 2000 7:37 AM > > Subject: RE: Draft Status Update > > > > > > > Paul, > > > > > > Based on the rule that the SIP-H.323 gateway appears to the endpoints as > > an > > > H.323 firewall, then this will work. If there ever is any difference, > > then > > > there is a problem > > > > > > I prefer to keep the "h323" designation. > > > > > > Bob > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Wednesday, November 29, 2000 8:33 PM > > > To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: Draft Status Update > > > > > > > > > Bob, > > > > > > I was not suggesting that we use the h323-ID field any differently-- it > > was > > > the "h323" field inside the supportedProtocols choice. It is used to > > > indicate a gateway that gateways to H.323 devices. However, it could > > serve > > > just as well to say it gateways to any IP telephony protocol. That's > why > > I > > > suggested we call it "ipgw". > > > > > > Whether we do that or add a "sip" field makes no difference to me, but > the > > > latter option may take 2 years. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > > > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; > > > <ITU-SG16(a)mailbag.cps.intel.com> > > > Sent: Wednesday, November 29, 2000 4:18 AM > > > Subject: RE: Draft Status Update > > > > > > > > > > Paul, > > > > > > > > I thought that the object of the IWF is to make the mixing of H.323 > > > > terminals and SIP terminals transparent. > > > > > > > > However, I could see supporting SIP: URLs in the H.323 URL field along > > > with > > > > the H.323 URL. This would be possible under the URL rules for > H.323v4. > > I > > > > would also expect SIP terminals to support the H.323 URL. > > > > > > > > The does not solve the problem of true E.164 Ids or the TEL: URL. A > > true > > > > E.164 Id does not allow for a service prefix. In that this is the > > normal > > > Id > > > > for voice calls, it must have a solution. An added problem is "Number > > > > Portability" which tends to kill number grouping. > > > > > > > > I do not accept the concept of hidden usages of any field. Therefor I > > do > > > > not support the use of the H.323ID field having a special format that > > > > indicates a SIP connection. The H.323ID field should remain a free > > format > > > > string. > > > > > > > > As it was stated, the gateway identifieds as having H.323 protocol is > > used > > > > by firewalls doing H.323-H.323. Also voice indicates any gateway > > support > > > > voice only connections. These should be mis-used. Adding a new > > protocol > > > > type for a gateway would have to wait. > > > > > > > > Bob > > > > > > > > -----Original Message----- > > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > > Sent: Tuesday, November 28, 2000 12:08 AM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: Draft Status Update > > > > > > > > > > > > Charles, > > > > > > > > I have discussed that idea with people before. > > > > > > > > I'm certainly open to the idea of adding a "sip" codepoint. However, > > > since > > > > H.323v4 was just approved, we'd have to wait for 2 years to get it in > > > there. > > > > We might be able to persuade folks to use the "h323" field for IP GWs > > and > > > > document that in the H.323 Implementers Guide-- perhaps even changing > > the > > > > name in v5 to "ipgw". > > > > > > > > Paul > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 04 Dec '00

04 Dec '00

Chris I said that the "....H.323 EP must support RAS...". We are down to the case where the H.323 EP user has disabled RAS. Is it useful to have this feature (third-party registration) for this specific case? Its not defined in the standard and I think it should be (i.e. From Pauls view, it could be useful for administrative reasons ); although there are ways to provide this feature in H.323v2 and H.323v4. Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, December 04, 2000 11:01 AM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, > By H.323 EP, I mean an H.323 EP that must support RAS (by your > interpretation of the standard), but the RAS function can be disabled by the > user (Pauls views ). The GK is an optional H.323 entity. I repeat that "The GK is an optional H.323 entity" does NOT imply "RAS is optional in an endpoint". >>Q4. Is Charles's actual application, where one entity is registering and >> hence >> presumably (although he's consistently failed to clarify) handling RAS on >> behalf of another compliant H.323 endpoint a possibility? >> A4a (My position, with which I THINK you agree) No, on the grounds that if >> the >> gateway/IWF can find a gatekeeper and use it, so can the endpoint. >> A4b (Charles) Yes. > A4b Yes, the H.323 EP user may have disabled RAS or the H.323 EP is turned > off (i.e. SIP EP). These are two complete separate cases. We were discussing only the (disputed) case that the H.323 EP user has disabled RAS. If the H.323 endpoint is turned off and a SIP endpoint is being used, the gateway is handling ALL H.323 call signalling on behalf of the SIP endpoint. In other words the gateway is terminating H.323 call signalling and, as far as H.323 is concerned, IS the endpoint. Or, to put it yet another way, the same device is handling RAS as is handling all other call signalling. Regards, Chris > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, December 01, 2000 3:36 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > > I am not a native English speaker (1/3), sorry for the mistake. I > > understand things better now. > I think we're getting closer now. Don't worry about not being a native > English > speaker - please persevere. I apologise if I've sometimes sounded harsh in > my > responses - it's normally because I'm trying to make points quickly! I know > communicating in a foreign language is hard - which is precisely why it's > important to make sure that nomenclature is clear and unambiguous! > > > Consider the following scenario; > > > > A4: > > > > An enpoint A (first-party) is switch off or does not "speak" H.323 (it > > supports RAS). I (third-party. i.e. IWF ) may want to be able to > > register this endpoint which we will call EP A. I register this > endpoint > > with its "well-known" alias address which is binded to a transport > addresses > > (not the one this EP usually uses when it is turned on. i.e. transport > > address of an H.323 complaint device like an answering machine called AM). > > The GK will now be able to route the call for EP A to the AM. For the EP > > that does not "speak" H.323 the signaling will go to some entity that > > will be able to "speak" H.323 and bind the RAS context created by the IWF > > (this may be the IWF itself). > > Ah! This is a COMPLETELY different scenario from that I was describing! > This > is simple. All you are doing here is registering an alias somewhere > different > from what you may consider its "usual home". The key to thinking about this > is > that aliases are just that - they may only bind to particular devices for > defined periods of time (the same user may use different endpoints on > different > days, but retain the same phone number). The practicalities between IWF and > the "transport address this endpoint uses when it is turned on" may get > somewhat hairy and certainly outside the remit of H.323, when it comes to > ensuring that you don't have multiple devices trying to use the same alias > in > the same zone simultaneously (sadly not permitted). > > > A5: If I have a GK in my network, I may not allow "dubious" EPs to have > > direct access to my GK. <misprint corrected> > True, but not addressing the question. The question is whether it is > permitted > to separate EP and GK with a proxy. I don't know the answer to this one! > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Friday, December 01, 2000 10:31 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > I'll take these two mails together, as the point is the same. > > > > H.225.0 section 7.7 states which RAS messages are mandatory, optional etc. > > for > > different H.323 devices. By mandating the support of these messages, it > > mandates the support of RAS, since there is no proviso there for "when > the > > EP/entity is supporting RAS". > > > > An aside, from a famous UK 80s sitcom on the subject of "clarification": > > "You don't issue clarifications to MAKE things clear: you issue them to > put > > you > > IN the clear." > > > > Regards, > > Chris > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Friday, December 01, 2000 10:46 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Paul, > > > > I think we're starting to converge. Let's separate this out now, into > > separate > > questions: > > > > Q1. Are endpoint devices (in which term I include gateways etc throughout > > this > > mail) required to implement RAS? > > A1. Yes (agreed between you and me, disagreed by Charles). > > > > Q2. How does an endpoint device know whether or not a gatekeeper is > present > > in > > the system, and hence whether or not to use RAS? > > A2a (Your position as I understand it.) Configuration, discovery on > > startup, > > give up if you don't find anything then. > > A2b (My suggestion) Configuration, discovery on startup, retry at some > > reasonable frequency (hourly?), take the three seconds to attempt > gatekeeper > > discovery when someone makes a call to or from the endpoint in question. > > A2c (What we'll probably end up agreeing!) Implementation decision. > > > > Q3. What should an endpoint do if it attempts to register with all > > discovered > > gatekeepers, where there is at least one gatekeeper in the system, and > fails > > (RRJ)? > > A3a (My position) Shut itself down. > > A3b (Anybody elses) ??? > > > > Q4. Is Charles's actual application, where one entity is registering and > > hence > > presumably (although he's consistently failed to clarify) handling RAS on > > behalf of another compliant H.323 endpoint a possibility? > > A4a (My position, with which I THINK you agree) No, on the grounds that if > > the > > gateway/IWF can find a gatekeeper and use it, so can the endpoint. > > A4b (Charles) Yes. > > > > This actually gives rise to a further question, which is (I believe) open, > > and > > probably shouldn't be: > > Q5. Can an endpoint be separated from its gatekeeper by a proxy? > > > > Regards, > > Chris > > > > Paul Long wrote: > > > > > > Chris, > > > > > > (You and I inadvertently replied to each other privately. I thought I'd > > > clean my email up a bit :-) and post it to the reflector.) > > > > > > As you point out, gatekeepers are optional, but an endpoint may not be > > > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > > > agree with you that an endpoint must implement and be able to use RAS. > The > > > tricky part, though, is under what circumstances _shall_ an endpoint use > > > RAS, i.e., at least attempt to register with a gatekeeper. It may come > > down > > > to a rather philosophical question. If an endpoint is required to use > RAS > > in > > > any way and ultimately discover and register with a gatekeeper only if > > there > > > is a gatekeeper in the "system," how does it know whether there is a > > > gatekeeper within the system without using RAS? Look like a Catch-22, > but > > my > > > take on it is that whether a gatekeeper is in the system must be known > out > > > of band. That's the only way I know of to resolve these otherwise > > > contradictory issues. > > > > > > Smith Micro builds endpoints that can be used in systems with and > without > > > gatekeepers. Because this vendor does not know whether the system within > > > which the user will be deploying the endpoint contains a gatekeeper, the > > > user presumably knows and has the discretion as whether to use RAS via a > > > Preferences dialog in the user interface. I think that's reasonable and > > > compliant. Some vendors may build endpoints that are designed to always > be > > > used within systems that contain gatekeepers, and that's fine, too, and > > > compliant. However, IMO, besides probably being a bad marketing decision > > > :-), an endpoint that does not support RAS at all is not compliant. > > > > > > Paul Long > > > ipDialog, Inc. > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Thursday, November 30, 2000 7:56 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > This comes up on this list every now and again, and the answer doesn't > > > change. > > > The gatekeeper is an optional entity: TRUE. > > > RAS is optional: FALSE. > > > Endpoints (including gateways, IWFs, whatever you want to call them) > have > > a > > > responsibility of trying to find one, registering with one if it can and > > > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but > > fails > > > to > > > register. Only if all reasonable attempts to find a gatekeeper fail > > should > > > an > > > H.323 endpoint operate without an active registration. > > > > > > Let me give you the first couple of quotations from H.323 (I'm looking > at > > v4 > > > determined, but I don't believe this has ever changed) I find on the > > > subject. > > > They're in section 7.2.2: > > > "As part of their configuration process, all endpoints shall > register..." > > > "Registration shall occur before any calls are attempted and may occur > > > periodically as necessary (for example, at endpoint power-up)." > > > > > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > > > messages" as well. > > > > > > How else could things work? Consider the case where an endpoint (A) is > > > trying > > > to make a call to another endpoint (B). A issues an ARQ to its > > gatekeeper, > > > asking permission to try a call; the gatekeeper rejects the call (ARJ) > on > > > some > > > reasonable grounds (possibly a conceptual "do not disturb" notice B has > > set > > > up > > > with its gatekeeper). A thinks "stuff this", unregisters from its > > > gatekeeper > > > ("we don't want to worry about all that boring RAS stuff if it's going > to > > be > > > inconvenient to us") and sends the Setup message to B anyway - resulting > > (at > > > best) in an disgruntled B. > > > In other words, as soon as you allow endpoints to operate in the > presence > > of > > > a > > > gatekeeper without registering with it and abiding by its decisions, you > > > might > > > as well write all xRJ messages out of the protocol entirely! > > > > > > If an endpoint is going to ignore RAS (and hence the standard) then why > > > should > > > it bother having anyone else register on its behalf? I refer you to > > > "Besides,..." in my last mail (which point you still haven't addressed). > > > > > > Regards, > > > Chris > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Agboh, Charles 04 Dec '00

04 Dec '00

Chris, By H.323 EP, I mean an H.323 EP that must support RAS (by your interpretation of the standard), but the RAS function can be disabled by the user (Pauls views ). The GK is an optional H.323 entity. >Q4. Is Charles's actual application, where one entity is registering and > hence > presumably (although he's consistently failed to clarify) handling RAS on > behalf of another compliant H.323 endpoint a possibility? > A4a (My position, with which I THINK you agree) No, on the grounds that if > the > gateway/IWF can find a gatekeeper and use it, so can the endpoint. > A4b (Charles) Yes. A4b Yes, the H.323 EP user may have disabled RAS or the H.323 EP is turned off (i.e. SIP EP). Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 3:36 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, > I am not a native English speaker (1/3), sorry for the mistake. I > understand things better now. I think we're getting closer now. Don't worry about not being a native English speaker - please persevere. I apologise if I've sometimes sounded harsh in my responses - it's normally because I'm trying to make points quickly! I know communicating in a foreign language is hard - which is precisely why it's important to make sure that nomenclature is clear and unambiguous! > Consider the following scenario; > > A4: > > An enpoint A (first-party) is switch off or does not "speak" H.323 (it > supports RAS). I (third-party. i.e. IWF ) may want to be able to > register this endpoint which we will call EP A. I register this endpoint > with its "well-known" alias address which is binded to a transport addresses > (not the one this EP usually uses when it is turned on. i.e. transport > address of an H.323 complaint device like an answering machine called AM). > The GK will now be able to route the call for EP A to the AM. For the EP > that does not "speak" H.323 the signaling will go to some entity that > will be able to "speak" H.323 and bind the RAS context created by the IWF > (this may be the IWF itself). Ah! This is a COMPLETELY different scenario from that I was describing! This is simple. All you are doing here is registering an alias somewhere different from what you may consider its "usual home". The key to thinking about this is that aliases are just that - they may only bind to particular devices for defined periods of time (the same user may use different endpoints on different days, but retain the same phone number). The practicalities between IWF and the "transport address this endpoint uses when it is turned on" may get somewhat hairy and certainly outside the remit of H.323, when it comes to ensuring that you don't have multiple devices trying to use the same alias in the same zone simultaneously (sadly not permitted). > A5: If I have a GK in my network, I may not allow "dubious" EPs to have > direct access to my GK. <misprint corrected> True, but not addressing the question. The question is whether it is permitted to separate EP and GK with a proxy. I don't know the answer to this one! Regards, Chris > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Friday, December 01, 2000 10:31 AM > To: Agboh, Charles > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Third party registration/group registration > > Charles, > > I'll take these two mails together, as the point is the same. > > H.225.0 section 7.7 states which RAS messages are mandatory, optional etc. > for > different H.323 devices. By mandating the support of these messages, it > mandates the support of RAS, since there is no proviso there for "when the > EP/entity is supporting RAS". > > An aside, from a famous UK 80s sitcom on the subject of "clarification": > "You don't issue clarifications to MAKE things clear: you issue them to put > you > IN the clear." > > Regards, > Chris > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, December 01, 2000 10:46 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Paul, > > I think we're starting to converge. Let's separate this out now, into > separate > questions: > > Q1. Are endpoint devices (in which term I include gateways etc throughout > this > mail) required to implement RAS? > A1. Yes (agreed between you and me, disagreed by Charles). > > Q2. How does an endpoint device know whether or not a gatekeeper is present > in > the system, and hence whether or not to use RAS? > A2a (Your position as I understand it.) Configuration, discovery on > startup, > give up if you don't find anything then. > A2b (My suggestion) Configuration, discovery on startup, retry at some > reasonable frequency (hourly?), take the three seconds to attempt gatekeeper > discovery when someone makes a call to or from the endpoint in question. > A2c (What we'll probably end up agreeing!) Implementation decision. > > Q3. What should an endpoint do if it attempts to register with all > discovered > gatekeepers, where there is at least one gatekeeper in the system, and fails > (RRJ)? > A3a (My position) Shut itself down. > A3b (Anybody elses) ??? > > Q4. Is Charles's actual application, where one entity is registering and > hence > presumably (although he's consistently failed to clarify) handling RAS on > behalf of another compliant H.323 endpoint a possibility? > A4a (My position, with which I THINK you agree) No, on the grounds that if > the > gateway/IWF can find a gatekeeper and use it, so can the endpoint. > A4b (Charles) Yes. > > This actually gives rise to a further question, which is (I believe) open, > and > probably shouldn't be: > Q5. Can an endpoint be separated from its gatekeeper by a proxy? > > Regards, > Chris > > Paul Long wrote: > > > > Chris, > > > > (You and I inadvertently replied to each other privately. I thought I'd > > clean my email up a bit :-) and post it to the reflector.) > > > > As you point out, gatekeepers are optional, but an endpoint may not be > > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > > agree with you that an endpoint must implement and be able to use RAS. The > > tricky part, though, is under what circumstances _shall_ an endpoint use > > RAS, i.e., at least attempt to register with a gatekeeper. It may come > down > > to a rather philosophical question. If an endpoint is required to use RAS > in > > any way and ultimately discover and register with a gatekeeper only if > there > > is a gatekeeper in the "system," how does it know whether there is a > > gatekeeper within the system without using RAS? Look like a Catch-22, but > my > > take on it is that whether a gatekeeper is in the system must be known out > > of band. That's the only way I know of to resolve these otherwise > > contradictory issues. > > > > Smith Micro builds endpoints that can be used in systems with and without > > gatekeepers. Because this vendor does not know whether the system within > > which the user will be deploying the endpoint contains a gatekeeper, the > > user presumably knows and has the discretion as whether to use RAS via a > > Preferences dialog in the user interface. I think that's reasonable and > > compliant. Some vendors may build endpoints that are designed to always be > > used within systems that contain gatekeepers, and that's fine, too, and > > compliant. However, IMO, besides probably being a bad marketing decision > > :-), an endpoint that does not support RAS at all is not compliant. > > > > Paul Long > > ipDialog, Inc. > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 7:56 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > This comes up on this list every now and again, and the answer doesn't > > change. > > The gatekeeper is an optional entity: TRUE. > > RAS is optional: FALSE. > > Endpoints (including gateways, IWFs, whatever you want to call them) have > a > > responsibility of trying to find one, registering with one if it can and > > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but > fails > > to > > register. Only if all reasonable attempts to find a gatekeeper fail > should > > an > > H.323 endpoint operate without an active registration. > > > > Let me give you the first couple of quotations from H.323 (I'm looking at > v4 > > determined, but I don't believe this has ever changed) I find on the > > subject. > > They're in section 7.2.2: > > "As part of their configuration process, all endpoints shall register..." > > "Registration shall occur before any calls are attempted and may occur > > periodically as necessary (for example, at endpoint power-up)." > > > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > > messages" as well. > > > > How else could things work? Consider the case where an endpoint (A) is > > trying > > to make a call to another endpoint (B). A issues an ARQ to its > gatekeeper, > > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > > some > > reasonable grounds (possibly a conceptual "do not disturb" notice B has > set > > up > > with its gatekeeper). A thinks "stuff this", unregisters from its > > gatekeeper > > ("we don't want to worry about all that boring RAS stuff if it's going to > be > > inconvenient to us") and sends the Setup message to B anyway - resulting > (at > > best) in an disgruntled B. > > In other words, as soon as you allow endpoints to operate in the presence > of > > a > > gatekeeper without registering with it and abiding by its decisions, you > > might > > as well write all xRJ messages out of the protocol entirely! > > > > If an endpoint is going to ignore RAS (and hence the standard) then why > > should > > it bother having anyone else register on its behalf? I refer you to > > "Besides,..." in my last mail (which point you still haven't addressed). > > > > Regards, > > Chris > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.323 Announcement List
by Paul E. Jones 03 Dec '00

03 Dec '00

Folks, I have set up a new mailing list called "h323-announce". Over the past year or so, I've noticed that many people miss important events relating to H.323, such as corrections that were made to the H.323v3 ASN.1. This new list is intended for those who want to be made aware of important issues relating to H.323, but who do not want to watch the SG16 or H.323 Implementers' lists from day to day for such important issues-- there are quite a few people in that category. This list is moderated and will be an extremely low-volume list. To subscribe, send e-mail to: h323-announce-request(a)packetizer.org In the body of the message, put "subscribe" Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: Draft Status Update
by Agboh, Charles 03 Dec '00

03 Dec '00

I inadvertently sent an incomplete version of this e-mail to the itu-sg16 mailing list, for that, I appologize. Paul, Bob; The SIP-H.323 gateway will be a gateway with multimedia capabilities. The focus now will be on voice and video. It is possible that other IP Telephony signaling protocols may be invented in the future and these may ask for codepoints in H.323. "ipgw" may be a way to provide a codepoint for the class of IP Telephony protocols. I am wondering what sort of information should be conveyed in such a structure (apart from the obvious): ipgw = seqence of { -protocol id ('sip', 'bicc',...) of type text string -.... }. Concering the current verison of the SIP-H.323 gw I(we) agree that "h323" should be used for now. Regards, charles -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Friday, December 01, 2000 8:30 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Draft Status Update Bob, I suppose it could, though I have not heard anybody focusing on multimedia in SIP. There are certainly a lot of missing pieces on that side for doing that. They could do audio and video at the very least. The folks I have heard from have been asking for a codepoint to advertise that the gateway is an H.323 to SIP gateway. The question is simply how to signal that? There's plenty of options, but we should select the one that makes the most sense. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)packetizer.com>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, December 01, 2000 3:49 AM Subject: RE: Draft Status Update > Paul, > > Actually a gateway should advertise "voice" if it only support voice. > Advertising "h323" means that the full multimedia suite of H.323 is > supported. What is the intent of the H.323 to SIP gateway? Will it > interwork the full multimedia suite? > > Bob > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Thursday, November 30, 2000 6:33 PM > To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Draft Status Update > > > Bob, > > The very fact that SIP is sitting on the back side of this H.323 device was > one reason I never pursued trying to add a "sip" codepoint, per se. Adding > "sip" as a codepoint might suggest that the SIP devices are doing RAS and I > know that would send shivers through the SIP community :-) > > Perhaps the right approach is to say that "h323" is the right choice and we > should clarify in H.225.0 that this codepoint is used to indicate an H.323 > GW that reaches other IP-based protocols. > > I think we need to say something, because this issue comes up from time to > time. People want to feel comfortable that when they register a gateway and > provide SIP interworking that they advertise the right protocol to the GK. > I don't see any reason why the GK should care whether the GW is actually > using SIP, BICC, or H.323 on the back side. > > Is there a technical reason why should or should not allow "h323" to be used > as I suggest above? I think we're in agreement that this does, indeed, act > like nothing more than an H.323 firewall and if it advertises the ability to > reach the desired destination-- I suppose that's all we need to care about. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Paul E. Jones'" <paulej(a)packetizer.com>; > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Thursday, November 30, 2000 7:37 AM > Subject: RE: Draft Status Update > > > > Paul, > > > > Based on the rule that the SIP-H.323 gateway appears to the endpoints as > an > > H.323 firewall, then this will work. If there ever is any difference, > then > > there is a problem > > > > I prefer to keep the "h323" designation. > > > > Bob > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Wednesday, November 29, 2000 8:33 PM > > To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Draft Status Update > > > > > > Bob, > > > > I was not suggesting that we use the h323-ID field any differently-- it > was > > the "h323" field inside the supportedProtocols choice. It is used to > > indicate a gateway that gateways to H.323 devices. However, it could > serve > > just as well to say it gateways to any IP telephony protocol. That's why > I > > suggested we call it "ipgw". > > > > Whether we do that or add a "sip" field makes no difference to me, but the > > latter option may take 2 years. > > > > Paul > > > > ----- Original Message ----- > > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; > > <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Wednesday, November 29, 2000 4:18 AM > > Subject: RE: Draft Status Update > > > > > > > Paul, > > > > > > I thought that the object of the IWF is to make the mixing of H.323 > > > terminals and SIP terminals transparent. > > > > > > However, I could see supporting SIP: URLs in the H.323 URL field along > > with > > > the H.323 URL. This would be possible under the URL rules for H.323v4. > I > > > would also expect SIP terminals to support the H.323 URL. > > > > > > The does not solve the problem of true E.164 Ids or the TEL: URL. A > true > > > E.164 Id does not allow for a service prefix. In that this is the > normal > > Id > > > for voice calls, it must have a solution. An added problem is "Number > > > Portability" which tends to kill number grouping. > > > > > > I do not accept the concept of hidden usages of any field. Therefor I > do > > > not support the use of the H.323ID field having a special format that > > > indicates a SIP connection. The H.323ID field should remain a free > format > > > string. > > > > > > As it was stated, the gateway identifieds as having H.323 protocol is > used > > > by firewalls doing H.323-H.323. Also voice indicates any gateway > support > > > voice only connections. These should be mis-used. Adding a new > protocol > > > type for a gateway would have to wait. > > > > > > Bob > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > Sent: Tuesday, November 28, 2000 12:08 AM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: Draft Status Update > > > > > > > > > Charles, > > > > > > I have discussed that idea with people before. > > > > > > I'm certainly open to the idea of adding a "sip" codepoint. However, > > since > > > H.323v4 was just approved, we'd have to wait for 2 years to get it in > > there. > > > We might be able to persuade folks to use the "h323" field for IP GWs > and > > > document that in the H.323 Implementers Guide-- perhaps even changing > the > > > name in v5 to "ipgw". > > > > > > Paul > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Outcome of the SG16 meeting
by Sakae OKUBO 03 Dec '00

03 Dec '00

Dear Mr. Maeng, >[...] Did we decide when we are >going to have the experts meeting and where? Interim Rapporteur meetings for audiovisual communication system Questions are planned as follows: 5-9 March 2001 in Melbourne hosted by Ericsson May/June 2001 date and place to be decided (Note) Note: This will be held if the next SG16 meeting (May/June 2001) is for one week as in November 2000. If it is two weeks long, the Rapporteur meeting will be cancelled. The SG16 meeting schedule is yet to be given. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: G.729 in H.245v7
by Francois Audet 01 Dec '00

01 Dec '00

OK Thanks. Pretty messy... But I guess it is the price of backward compatibility. > -----Original Message----- > From: Simao Campos [mailto:simao.campos@labs.comsat.com] > Sent: Friday, December 01, 2000 11:00 AM > To: Audet, Francois [SC2:4K02:EXCH] > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: G.729 in H.245v7 > > > Francois > > > So my question is: when are the Annex A and Annex B flag used in > > g729Extensions? > > For example, if you want to have VAD operation (Annex B) with G.729A > and is also capable say of 6.4 kb/s operation (Annex D). Then you > would set the flags for A, B, and D. Another example, if you have an > implementation with G.729A and G.729D (6.4 kb/s), then you would have > the flags for Annexes A and D set. > > In my understanding, g729AnnexA, g729wAnnexB and g729AnnexAwAnnexB, > for which g729AnnexA, g729AnnexB and g729AnnexAwAnnexB should be used > only if the additional modes are not used (Annex D and E and the > different combinations with G.729 Main body, Annex A, and > Annex B). It > was actually a short-sightedness on our part when the codepoints were > first defined. > > I hope this helps, > Simao > >

1 0

RE: Draft Status Update
by Callaghan, Robert 01 Dec '00

01 Dec '00

Paul, Actually a gateway should advertise "voice" if it only support voice. Advertising "h323" means that the full multimedia suite of H.323 is supported. What is the intent of the H.323 to SIP gateway? Will it interwork the full multimedia suite? Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, November 30, 2000 6:33 PM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Draft Status Update Bob, The very fact that SIP is sitting on the back side of this H.323 device was one reason I never pursued trying to add a "sip" codepoint, per se. Adding "sip" as a codepoint might suggest that the SIP devices are doing RAS and I know that would send shivers through the SIP community :-) Perhaps the right approach is to say that "h323" is the right choice and we should clarify in H.225.0 that this codepoint is used to indicate an H.323 GW that reaches other IP-based protocols. I think we need to say something, because this issue comes up from time to time. People want to feel comfortable that when they register a gateway and provide SIP interworking that they advertise the right protocol to the GK. I don't see any reason why the GK should care whether the GW is actually using SIP, BICC, or H.323 on the back side. Is there a technical reason why should or should not allow "h323" to be used as I suggest above? I think we're in agreement that this does, indeed, act like nothing more than an H.323 firewall and if it advertises the ability to reach the desired destination-- I suppose that's all we need to care about. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)packetizer.com>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Thursday, November 30, 2000 7:37 AM Subject: RE: Draft Status Update > Paul, > > Based on the rule that the SIP-H.323 gateway appears to the endpoints as an > H.323 firewall, then this will work. If there ever is any difference, then > there is a problem > > I prefer to keep the "h323" designation. > > Bob > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, November 29, 2000 8:33 PM > To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Draft Status Update > > > Bob, > > I was not suggesting that we use the h323-ID field any differently-- it was > the "h323" field inside the supportedProtocols choice. It is used to > indicate a gateway that gateways to H.323 devices. However, it could serve > just as well to say it gateways to any IP telephony protocol. That's why I > suggested we call it "ipgw". > > Whether we do that or add a "sip" field makes no difference to me, but the > latter option may take 2 years. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, November 29, 2000 4:18 AM > Subject: RE: Draft Status Update > > > > Paul, > > > > I thought that the object of the IWF is to make the mixing of H.323 > > terminals and SIP terminals transparent. > > > > However, I could see supporting SIP: URLs in the H.323 URL field along > with > > the H.323 URL. This would be possible under the URL rules for H.323v4. I > > would also expect SIP terminals to support the H.323 URL. > > > > The does not solve the problem of true E.164 Ids or the TEL: URL. A true > > E.164 Id does not allow for a service prefix. In that this is the normal > Id > > for voice calls, it must have a solution. An added problem is "Number > > Portability" which tends to kill number grouping. > > > > I do not accept the concept of hidden usages of any field. Therefor I do > > not support the use of the H.323ID field having a special format that > > indicates a SIP connection. The H.323ID field should remain a free format > > string. > > > > As it was stated, the gateway identifieds as having H.323 protocol is used > > by firewalls doing H.323-H.323. Also voice indicates any gateway support > > voice only connections. These should be mis-used. Adding a new protocol > > type for a gateway would have to wait. > > > > Bob > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Sent: Tuesday, November 28, 2000 12:08 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Draft Status Update > > > > > > Charles, > > > > I have discussed that idea with people before. > > > > I'm certainly open to the idea of adding a "sip" codepoint. However, > since > > H.323v4 was just approved, we'd have to wait for 2 years to get it in > there. > > We might be able to persuade folks to use the "h323" field for IP GWs and > > document that in the H.323 Implementers Guide-- perhaps even changing the > > name in v5 to "ipgw". > > > > Paul > >

2 1

G.729 in H.245v7
by Francois Audet 01 Dec '00

01 Dec '00

I was looking at H.245v7, and we have added a field called g729Extensions to the g729 audio capability. In the g729Extensions field there are boolean flags for G.729 annexes A, B, C, D, E, F, G, and H. There is a paragraph saying: g729Extensions: indicates capability of additional optional modes of G.729. This codepoint shall not be used to indicate g729AnnexA, g729wAnnexB and g729AnnexAwAnnexB, for which g729AnnexA, g729AnnexB and g729AnnexAwAnnexB shall be used. So my question is: when are the Annex A and Annex B flag used in g729Extensions? Thanks. ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Re: Third party registration/group registration
by Agboh, Charles 01 Dec '00

01 Dec '00

Chris, I am not a native English speaker (1/3), sorry for the mistake. I understand things better now. Consider the following scenario; A4: An enpoint A (first-party) is switch off or does not "speak" H.323 (it supports RAS). I (third-party. i.e. IWF ) may want to be able to register this endpoint which we will call EP A. I register this endpoint with its "well-known" alias address which is binded to a transport addresses (not the one this EP usually uses when it is turned on. i.e. transport address of an H.323 complaint device like an answering machine called AM). The GK will now be able to route the call for EP A to the AM. For the EP that does not "speak" H.323 the signaling will go to some entity that will be able to "speak" H.323 and bind the RAS context created by the IWF (this may be the IWF itself). A5: If I have a GK in my network, I may not allow "dubious" EPs to have direct access to my EP. Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, December 01, 2000 10:31 AM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, I'll take these two mails together, as the point is the same. H.225.0 section 7.7 states which RAS messages are mandatory, optional etc. for different H.323 devices. By mandating the support of these messages, it mandates the support of RAS, since there is no proviso there for "when the EP/entity is supporting RAS". An aside, from a famous UK 80s sitcom on the subject of "clarification": "You don't issue clarifications to MAKE things clear: you issue them to put you IN the clear." Regards, Chris -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 10:46 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Paul, I think we're starting to converge. Let's separate this out now, into separate questions: Q1. Are endpoint devices (in which term I include gateways etc throughout this mail) required to implement RAS? A1. Yes (agreed between you and me, disagreed by Charles). Q2. How does an endpoint device know whether or not a gatekeeper is present in the system, and hence whether or not to use RAS? A2a (Your position as I understand it.) Configuration, discovery on startup, give up if you don't find anything then. A2b (My suggestion) Configuration, discovery on startup, retry at some reasonable frequency (hourly?), take the three seconds to attempt gatekeeper discovery when someone makes a call to or from the endpoint in question. A2c (What we'll probably end up agreeing!) Implementation decision. Q3. What should an endpoint do if it attempts to register with all discovered gatekeepers, where there is at least one gatekeeper in the system, and fails (RRJ)? A3a (My position) Shut itself down. A3b (Anybody elses) ??? Q4. Is Charles's actual application, where one entity is registering and hence presumably (although he's consistently failed to clarify) handling RAS on behalf of another compliant H.323 endpoint a possibility? A4a (My position, with which I THINK you agree) No, on the grounds that if the gateway/IWF can find a gatekeeper and use it, so can the endpoint. A4b (Charles) Yes. This actually gives rise to a further question, which is (I believe) open, and probably shouldn't be: Q5. Can an endpoint be separated from its gatekeeper by a proxy? Regards, Chris Paul Long wrote: > > Chris, > > (You and I inadvertently replied to each other privately. I thought I'd > clean my email up a bit :-) and post it to the reflector.) > > As you point out, gatekeepers are optional, but an endpoint may not be > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > agree with you that an endpoint must implement and be able to use RAS. The > tricky part, though, is under what circumstances _shall_ an endpoint use > RAS, i.e., at least attempt to register with a gatekeeper. It may come down > to a rather philosophical question. If an endpoint is required to use RAS in > any way and ultimately discover and register with a gatekeeper only if there > is a gatekeeper in the "system," how does it know whether there is a > gatekeeper within the system without using RAS? Look like a Catch-22, but my > take on it is that whether a gatekeeper is in the system must be known out > of band. That's the only way I know of to resolve these otherwise > contradictory issues. > > Smith Micro builds endpoints that can be used in systems with and without > gatekeepers. Because this vendor does not know whether the system within > which the user will be deploying the endpoint contains a gatekeeper, the > user presumably knows and has the discretion as whether to use RAS via a > Preferences dialog in the user interface. I think that's reasonable and > compliant. Some vendors may build endpoints that are designed to always be > used within systems that contain gatekeepers, and that's fine, too, and > compliant. However, IMO, besides probably being a bad marketing decision > :-), an endpoint that does not support RAS at all is not compliant. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 7:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by BOUGANT Fran�ois FTRD/DAC/ISS 01 Dec '00

01 Dec '00

Chris, I don't understand your position on Q3. An endpoint shall attempt to register with all discovered GKs (at least one) only if this endpoint has received at least one GCF message from any GK. My understanding is that a GK returning a GCF message to an endpoint (after having previously received a GRQ message from this endpoint) is active and implicitly ready to register the endpoint; if not the GK shall return a GRJ message. The RRJ message is used by the GK to indicate that the registration has failed and indicates the reason. I think that the endpoint shall re-send a RRQ message with corrections (when possible). If the rejection occurs several times, the endpoint may shut down to re-initialize and re-start the GK discovery procedure. Regards, François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail : francois.bougant(a)francetelecom.fr 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42 -----Message d'origine----- De : Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Envoyé : vendredi 1 décembre 2000 10:46 À : ITU-SG16(a)MAILBAG.INTEL.COM Objet : Re: Third party registration/group registration Paul, I think we're starting to converge. Let's separate this out now, into separate questions: Q1. Are endpoint devices (in which term I include gateways etc throughout this mail) required to implement RAS? A1. Yes (agreed between you and me, disagreed by Charles). Q2. How does an endpoint device know whether or not a gatekeeper is present in the system, and hence whether or not to use RAS? A2a (Your position as I understand it.) Configuration, discovery on startup, give up if you don't find anything then. A2b (My suggestion) Configuration, discovery on startup, retry at some reasonable frequency (hourly?), take the three seconds to attempt gatekeeper discovery when someone makes a call to or from the endpoint in question. A2c (What we'll probably end up agreeing!) Implementation decision. Q3. What should an endpoint do if it attempts to register with all discovered gatekeepers, where there is at least one gatekeeper in the system, and fails (RRJ)? A3a (My position) Shut itself down. A3b (Anybody elses) ??? Q4. Is Charles's actual application, where one entity is registering and hence presumably (although he's consistently failed to clarify) handling RAS on behalf of another compliant H.323 endpoint a possibility? A4a (My position, with which I THINK you agree) No, on the grounds that if the gateway/IWF can find a gatekeeper and use it, so can the endpoint. A4b (Charles) Yes. This actually gives rise to a further question, which is (I believe) open, and probably shouldn't be: Q5. Can an endpoint be separated from its gatekeeper by a proxy? Regards, Chris Paul Long wrote: > > Chris, > > (You and I inadvertently replied to each other privately. I thought I'd > clean my email up a bit :-) and post it to the reflector.) > > As you point out, gatekeepers are optional, but an endpoint may not be > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > agree with you that an endpoint must implement and be able to use RAS. The > tricky part, though, is under what circumstances _shall_ an endpoint use > RAS, i.e., at least attempt to register with a gatekeeper. It may come down > to a rather philosophical question. If an endpoint is required to use RAS in > any way and ultimately discover and register with a gatekeeper only if there > is a gatekeeper in the "system," how does it know whether there is a > gatekeeper within the system without using RAS? Look like a Catch-22, but my > take on it is that whether a gatekeeper is in the system must be known out > of band. That's the only way I know of to resolve these otherwise > contradictory issues. > > Smith Micro builds endpoints that can be used in systems with and without > gatekeepers. Because this vendor does not know whether the system within > which the user will be deploying the endpoint contains a gatekeeper, the > user presumably knows and has the discretion as whether to use RAS via a > Preferences dialog in the user interface. I think that's reasonable and > compliant. Some vendors may build endpoints that are designed to always be > used within systems that contain gatekeepers, and that's fine, too, and > compliant. However, IMO, besides probably being a bad marketing decision > :-), an endpoint that does not support RAS at all is not compliant. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 7:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Agboh, Charles 01 Dec '00

01 Dec '00

in A5, I meant GK in the last line. -charles -----Original Message----- From: Agboh, Charles Sent: Friday, December 01, 2000 12:27 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Chris, I am not a native English speaker (1/3), sorry for the mistake. I understand things better now. Consider the following scenario; A4: An enpoint A (first-party) is switch off or does not "speak" H.323 (it supports RAS). I (third-party. i.e. IWF ) may want to be able to register this endpoint which we will call EP A. I register this endpoint with its "well-known" alias address which is binded to a transport addresses (not the one this EP usually uses when it is turned on. i.e. transport address of an H.323 complaint device like an answering machine called AM). The GK will now be able to route the call for EP A to the AM. For the EP that does not "speak" H.323 the signaling will go to some entity that will be able to "speak" H.323 and bind the RAS context created by the IWF (this may be the IWF itself). A5: If I have a GK in my network, I may not allow "dubious" EPs to have direct access to my EP. Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, December 01, 2000 10:31 AM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, I'll take these two mails together, as the point is the same. H.225.0 section 7.7 states which RAS messages are mandatory, optional etc. for different H.323 devices. By mandating the support of these messages, it mandates the support of RAS, since there is no proviso there for "when the EP/entity is supporting RAS". An aside, from a famous UK 80s sitcom on the subject of "clarification": "You don't issue clarifications to MAKE things clear: you issue them to put you IN the clear." Regards, Chris -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 01, 2000 10:46 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Paul, I think we're starting to converge. Let's separate this out now, into separate questions: Q1. Are endpoint devices (in which term I include gateways etc throughout this mail) required to implement RAS? A1. Yes (agreed between you and me, disagreed by Charles). Q2. How does an endpoint device know whether or not a gatekeeper is present in the system, and hence whether or not to use RAS? A2a (Your position as I understand it.) Configuration, discovery on startup, give up if you don't find anything then. A2b (My suggestion) Configuration, discovery on startup, retry at some reasonable frequency (hourly?), take the three seconds to attempt gatekeeper discovery when someone makes a call to or from the endpoint in question. A2c (What we'll probably end up agreeing!) Implementation decision. Q3. What should an endpoint do if it attempts to register with all discovered gatekeepers, where there is at least one gatekeeper in the system, and fails (RRJ)? A3a (My position) Shut itself down. A3b (Anybody elses) ??? Q4. Is Charles's actual application, where one entity is registering and hence presumably (although he's consistently failed to clarify) handling RAS on behalf of another compliant H.323 endpoint a possibility? A4a (My position, with which I THINK you agree) No, on the grounds that if the gateway/IWF can find a gatekeeper and use it, so can the endpoint. A4b (Charles) Yes. This actually gives rise to a further question, which is (I believe) open, and probably shouldn't be: Q5. Can an endpoint be separated from its gatekeeper by a proxy? Regards, Chris Paul Long wrote: > > Chris, > > (You and I inadvertently replied to each other privately. I thought I'd > clean my email up a bit :-) and post it to the reflector.) > > As you point out, gatekeepers are optional, but an endpoint may not be > registered with a gatekeeper (hence, an "unregistered endpoint"). I also > agree with you that an endpoint must implement and be able to use RAS. The > tricky part, though, is under what circumstances _shall_ an endpoint use > RAS, i.e., at least attempt to register with a gatekeeper. It may come down > to a rather philosophical question. If an endpoint is required to use RAS in > any way and ultimately discover and register with a gatekeeper only if there > is a gatekeeper in the "system," how does it know whether there is a > gatekeeper within the system without using RAS? Look like a Catch-22, but my > take on it is that whether a gatekeeper is in the system must be known out > of band. That's the only way I know of to resolve these otherwise > contradictory issues. > > Smith Micro builds endpoints that can be used in systems with and without > gatekeepers. Because this vendor does not know whether the system within > which the user will be deploying the endpoint contains a gatekeeper, the > user presumably knows and has the discretion as whether to use RAS via a > Preferences dialog in the user interface. I think that's reasonable and > compliant. Some vendors may build endpoints that are designed to always be > used within systems that contain gatekeepers, and that's fine, too, and > compliant. However, IMO, besides probably being a bad marketing decision > :-), an endpoint that does not support RAS at all is not compliant. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 7:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 01 Dec '00

01 Dec '00

Hi Roy, Chris; RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the sigalals are incoming or outgoing. Please, just indicate where in H.323 RAS is mandated. Regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Thursday, November 30, 2000 6:33 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Hi, Chris: Yes, I do. Regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, November 30, 2000 12:01 PM To: ITU-SG16(a)mailbag.cps.intel.com Cc: Roy, Radhika R, ALCOO Subject: Re: Third party registration/group registration All, A clarification: I am sure Radhika will agree that when he refers to call setup this includes the case of incoming call setup as well as that of outgoing call setup! Regards, Chris "Roy, Radhika R, ALCOO" wrote: > > Hi, All: > > Let me add a little. > > An H.323 entity needs to have the capability to support RAS messages. > However, whether the RAS messages will be used or not before the call setup > is up to that entity. > > Best regards, > Radhika > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 8:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, > > > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 12:49 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > > The answer to your first question depends on the capabilities of D. > > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > > In my last email, the "third-party" would be a C device and > "first-party" > > > would be a D device (second-party is the A device) . > > RUBBISH! > > RAS is NOT optional. See Table 18/H.225.0. > > Besides, how would your crippled H.323 endpoint tell its RAS handler to > send > > the various RAS messages (like for instance ARQ to ask permission to make > a > > call...)? > > > > Regards, > > Chris > > > > > > > > Regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Thursday, November 30, 2000 10:43 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > In your definition of "third-party" registration, consider a scenario > > > involving > > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > > behalf C > > > is registering (which we'll call D). Assuming that B is not routing > > > call-signalling, to which entity would A send its "Setup" message in > order > > > to > > > contact D? > > > > > > If the answer to this question is "C", this is well-covered in the > > standard > > > - > > > it is simply that the term "third-party registration" is not used for > it. > > > It > > > is simply viewed as C registering (potentially) lots of aliases. This > > > parallels Tom's second case. > > > If the answer is "D" (parallelling Tom's first case), then D is a very > odd > > > device (it can't be a full H.323 implementation or it would register for > > > itself). Why have a device implementing all of H.323 except gatekeeper > > > registration? After all, D would have to handle all the rest of RAS for > > > itself > > > - what would it be gaining by not registering on its own behalf? > > > > > > In the same scenario, to what entities are you referring, respectively, > as > > > the > > > "third-party" in your latest contribution? > > > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > > cases > > > where you use these terms. I am certain that the ends you are trying to > > > achieve are perfectly possible - and not even that hard. Either will > > > result, I > > > believe, in a brief discussion with early consensus emerging. I believe > > the > > > problems, and the large amount of mail this is generating on this list, > > come > > > about entirely from the use of these terms without anyone understanding > > > exactly > > > what is meant by them. > > > > > > I agree with Tom that once we can agree on terminology we can move on > > quite > > > easily, and thank him for his usual high-quality clear-sighted input. > > > > > > Regards, > > > Chris > > > > > > ------------------------------------ > > > > > > The registration feature allows endpoints to bind their identities to > > > transport > > > address(es) at the GK. This is well described in H.323. When an > > endpoint > > > delegates another endpoint to perform this fearture on its behalf the > > > definition in H.323 is not there. The signaling that follows the > > > registration > > > whether, its > > > first or third-party may interrogate this binding. The third-party > > > registration feature can enhance the user experience much more than a > > normal > > > first-party > > > registration. I don't believe that the third-party has to be in the > > > signaling > > > flow that may follow the third-registration. I agree with Tom-PTs > view. > > > > > > Best regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > Sent: Wednesday, November 29, 2000 7:39 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Accurate terminology is obviously useful, but in this case, at > least, > > it > > > looks like something people can agree on and then move on. The more > > > important point seems to be the underlying distinction in > > requirements: > > > > > > -- register on behalf of H.323 endpoints > > > -- register on behalf of other endpoints > > > where I use "other" in the sense that the contact address is > > associated > > > with a non-H.323 signalling protocol. Purity is beside the point here > -- > > > it's the intention of the contact address that matters. Stating the > > > requirement in this way makes it obvious that the second requirement > > > includes > > > the need to state which protocol the endpoints expects to receive. > > > > > > There is another possibility, of course: use the same mechanism to > > > satisfy > > > all requirements, and allow for the possibility that the endpoint > > > supports multiple protocols. I think the design would be cleaner if > > we > > > took the approach: one contact point, one protocol -- even if it meant > > > repeating the contact information for each protocol a multiprotocol > > > endpoint supports. > > > > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 30 Nov '00

30 Nov '00

Hi, Charles: Pl. see the statement carefully. The use of RAS is Optional, but RAS needs to be supported. Thanks, Radhika -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@gts.com] Sent: Thursday, November 30, 2000 12:49 PM To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: Third party registration/group registration Hi Roy, Chris; RAS is RECOMMENDED. It is NOT MANDATORY (hence optional) whether the sigalals are incoming or outgoing. Please, just indicate where in H.323 RAS is mandated. Regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Thursday, November 30, 2000 6:33 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Hi, Chris: Yes, I do. Regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, November 30, 2000 12:01 PM To: ITU-SG16(a)mailbag.cps.intel.com Cc: Roy, Radhika R, ALCOO Subject: Re: Third party registration/group registration All, A clarification: I am sure Radhika will agree that when he refers to call setup this includes the case of incoming call setup as well as that of outgoing call setup! Regards, Chris "Roy, Radhika R, ALCOO" wrote: > > Hi, All: > > Let me add a little. > > An H.323 entity needs to have the capability to support RAS messages. > However, whether the RAS messages will be used or not before the call setup > is up to that entity. > > Best regards, > Radhika > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 8:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, > > > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 12:49 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > > The answer to your first question depends on the capabilities of D. > > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > > In my last email, the "third-party" would be a C device and > "first-party" > > > would be a D device (second-party is the A device) . > > RUBBISH! > > RAS is NOT optional. See Table 18/H.225.0. > > Besides, how would your crippled H.323 endpoint tell its RAS handler to > send > > the various RAS messages (like for instance ARQ to ask permission to make > a > > call...)? > > > > Regards, > > Chris > > > > > > > > Regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Thursday, November 30, 2000 10:43 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > In your definition of "third-party" registration, consider a scenario > > > involving > > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > > behalf C > > > is registering (which we'll call D). Assuming that B is not routing > > > call-signalling, to which entity would A send its "Setup" message in > order > > > to > > > contact D? > > > > > > If the answer to this question is "C", this is well-covered in the > > standard > > > - > > > it is simply that the term "third-party registration" is not used for > it. > > > It > > > is simply viewed as C registering (potentially) lots of aliases. This > > > parallels Tom's second case. > > > If the answer is "D" (parallelling Tom's first case), then D is a very > odd > > > device (it can't be a full H.323 implementation or it would register for > > > itself). Why have a device implementing all of H.323 except gatekeeper > > > registration? After all, D would have to handle all the rest of RAS for > > > itself > > > - what would it be gaining by not registering on its own behalf? > > > > > > In the same scenario, to what entities are you referring, respectively, > as > > > the > > > "third-party" in your latest contribution? > > > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > > cases > > > where you use these terms. I am certain that the ends you are trying to > > > achieve are perfectly possible - and not even that hard. Either will > > > result, I > > > believe, in a brief discussion with early consensus emerging. I believe > > the > > > problems, and the large amount of mail this is generating on this list, > > come > > > about entirely from the use of these terms without anyone understanding > > > exactly > > > what is meant by them. > > > > > > I agree with Tom that once we can agree on terminology we can move on > > quite > > > easily, and thank him for his usual high-quality clear-sighted input. > > > > > > Regards, > > > Chris > > > > > > ------------------------------------ > > > > > > The registration feature allows endpoints to bind their identities to > > > transport > > > address(es) at the GK. This is well described in H.323. When an > > endpoint > > > delegates another endpoint to perform this fearture on its behalf the > > > definition in H.323 is not there. The signaling that follows the > > > registration > > > whether, its > > > first or third-party may interrogate this binding. The third-party > > > registration feature can enhance the user experience much more than a > > normal > > > first-party > > > registration. I don't believe that the third-party has to be in the > > > signaling > > > flow that may follow the third-registration. I agree with Tom-PTs > view. > > > > > > Best regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > Sent: Wednesday, November 29, 2000 7:39 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Accurate terminology is obviously useful, but in this case, at > least, > > it > > > looks like something people can agree on and then move on. The more > > > important point seems to be the underlying distinction in > > requirements: > > > > > > -- register on behalf of H.323 endpoints > > > -- register on behalf of other endpoints > > > where I use "other" in the sense that the contact address is > > associated > > > with a non-H.323 signalling protocol. Purity is beside the point here > -- > > > it's the intention of the contact address that matters. Stating the > > > requirement in this way makes it obvious that the second requirement > > > includes > > > the need to state which protocol the endpoints expects to receive. > > > > > > There is another possibility, of course: use the same mechanism to > > > satisfy > > > all requirements, and allow for the possibility that the endpoint > > > supports multiple protocols. I think the design would be cleaner if > > we > > > took the approach: one contact point, one protocol -- even if it meant > > > repeating the contact information for each protocol a multiprotocol > > > endpoint supports. > > > > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: FastConnect W/O any OLC - can it be?
by Francois Audet 30 Nov '00

30 Nov '00

No (except for Annex F terminals). We had that discussions in standards. Just do H.245 TCS and M/S determination after fastStart has completed (preferably using H.245 tunnelling). Then you can use the null TCS procedures of 8.4.6/H.323. > -----Original Message----- > From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM] > Sent: Thursday, November 30, 2000 10:10 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FastConnect W/O any OLC - can it be? > > > Would that be a way to do a third-party initiated pause when using > FastConnect? > > charles > > -----Original Message----- > From: Adi Shmul [mailto:adi@tundo.com] > Sent: Thursday, November 30, 2000 6:29 PM > To: h323implementors(a)imtc.org > Subject: FastConnect W/O any OLC - can it be? > > > > > Regards > Adi Shmul > Standards & Interoperability Manager > Tundo > Tel: +1-866-9388636 ext. 271 > Cell: +972-54-852229 > Fax: +972-9-8852249 > P.O.B 8420 > Natanya 42505 > Israel > Site: http://www.tundo.com/ > > > > > -------------------------------------------------------------- > ------------- > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > -------------------------------------------------------------- > ------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: FastConnect W/O any OLC - can it be?
by Agboh, Charles 30 Nov '00

30 Nov '00

Would that be a way to do a third-party initiated pause when using FastConnect? charles -----Original Message----- From: Adi Shmul [mailto:adi@tundo.com] Sent: Thursday, November 30, 2000 6:29 PM To: h323implementors(a)imtc.org Subject: FastConnect W/O any OLC - can it be? Regards Adi Shmul Standards & Interoperability Manager Tundo Tel: +1-866-9388636 ext. 271 Cell: +972-54-852229 Fax: +972-9-8852249 P.O.B 8420 Natanya 42505 Israel Site: http://www.tundo.com/ --------------------------------------------------------------------------- ------------------------------ Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------ --------------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 30 Nov '00

30 Nov '00

Chris, Clarification: The examples you give only suggest the RAS parameters and messages that must be supported when the EP/entity is supporting RAS. Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 2:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, This comes up on this list every now and again, and the answer doesn't change. The gatekeeper is an optional entity: TRUE. RAS is optional: FALSE. Endpoints (including gateways, IWFs, whatever you want to call them) have a responsibility of trying to find one, registering with one if it can and SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails to register. Only if all reasonable attempts to find a gatekeeper fail should an H.323 endpoint operate without an active registration. Let me give you the first couple of quotations from H.323 (I'm looking at v4 determined, but I don't believe this has ever changed) I find on the subject. They're in section 7.2.2: "As part of their configuration process, all endpoints shall register..." "Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up)." Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS messages" as well. How else could things work? Consider the case where an endpoint (A) is trying to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, asking permission to try a call; the gatekeeper rejects the call (ARJ) on some reasonable grounds (possibly a conceptual "do not disturb" notice B has set up with its gatekeeper). A thinks "stuff this", unregisters from its gatekeeper ("we don't want to worry about all that boring RAS stuff if it's going to be inconvenient to us") and sends the Setup message to B anyway - resulting (at best) in an disgruntled B. In other words, as soon as you allow endpoints to operate in the presence of a gatekeeper without registering with it and abiding by its decisions, you might as well write all xRJ messages out of the protocol entirely! If an endpoint is going to ignore RAS (and hence the standard) then why should it bother having anyone else register on its behalf? I refer you to "Besides,..." in my last mail (which point you still haven't addressed). Regards, Chris "Agboh, Charles" wrote: > > Chris, > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 12:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > > The answer to your first question depends on the capabilities of D. > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > In my last email, the "third-party" would be a C device and "first-party" > > would be a D device (second-party is the A device) . > RUBBISH! > RAS is NOT optional. See Table 18/H.225.0. > Besides, how would your crippled H.323 endpoint tell its RAS handler to send > the various RAS messages (like for instance ARQ to ask permission to make a > call...)? > > Regards, > Chris > > > > > Regards, > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 10:43 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > In your definition of "third-party" registration, consider a scenario > > involving > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > behalf C > > is registering (which we'll call D). Assuming that B is not routing > > call-signalling, to which entity would A send its "Setup" message in order > > to > > contact D? > > > > If the answer to this question is "C", this is well-covered in the > standard > > - > > it is simply that the term "third-party registration" is not used for it. > > It > > is simply viewed as C registering (potentially) lots of aliases. This > > parallels Tom's second case. > > If the answer is "D" (parallelling Tom's first case), then D is a very odd > > device (it can't be a full H.323 implementation or it would register for > > itself). Why have a device implementing all of H.323 except gatekeeper > > registration? After all, D would have to handle all the rest of RAS for > > itself > > - what would it be gaining by not registering on its own behalf? > > > > In the same scenario, to what entities are you referring, respectively, as > > the > > "third-party" in your latest contribution? > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > cases > > where you use these terms. I am certain that the ends you are trying to > > achieve are perfectly possible - and not even that hard. Either will > > result, I > > believe, in a brief discussion with early consensus emerging. I believe > the > > problems, and the large amount of mail this is generating on this list, > come > > about entirely from the use of these terms without anyone understanding > > exactly > > what is meant by them. > > > > I agree with Tom that once we can agree on terminology we can move on > quite > > easily, and thank him for his usual high-quality clear-sighted input. > > > > Regards, > > Chris > > > > ------------------------------------ > > > > The registration feature allows endpoints to bind their identities to > > transport > > address(es) at the GK. This is well described in H.323. When an > endpoint > > delegates another endpoint to perform this fearture on its behalf the > > definition in H.323 is not there. The signaling that follows the > > registration > > whether, its > > first or third-party may interrogate this binding. The third-party > > registration feature can enhance the user experience much more than a > normal > > first-party > > registration. I don't believe that the third-party has to be in the > > signaling > > flow that may follow the third-registration. I agree with Tom-PTs view. > > > > Best regards, > > > > charles > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > Sent: Wednesday, November 29, 2000 7:39 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Accurate terminology is obviously useful, but in this case, at least, > it > > looks like something people can agree on and then move on. The more > > important point seems to be the underlying distinction in > requirements: > > > > -- register on behalf of H.323 endpoints > > -- register on behalf of other endpoints > > where I use "other" in the sense that the contact address is > associated > > with a non-H.323 signalling protocol. Purity is beside the point here -- > > it's the intention of the contact address that matters. Stating the > > requirement in this way makes it obvious that the second requirement > > includes > > the need to state which protocol the endpoints expects to receive. > > > > There is another possibility, of course: use the same mechanism to > > satisfy > > all requirements, and allow for the possibility that the endpoint > > supports multiple protocols. I think the design would be cleaner if > we > > took the approach: one contact point, one protocol -- even if it meant > > repeating the contact information for each protocol a multiprotocol > > endpoint supports. > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0