December 2000 - sg16-avd - lists.packetizer.com

None
by Delphi 07 Dec '00

07 Dec '00

Hi'al: Can anybody tell me how to join this mail list? Thanks, ---Delphi *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Qi Zongjun Software Development Engineer IP R&D, Capitel Group No.5 Jiang Tai Road, Chao Yang District Beijing 100016 China Tel: +86-10-64317906 (or) +86-10-64375731 Ext 5691 E-mail: qizj(a)capitel.com.cn ☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

2 1

Global Call Reference Value
by Paul E. Jones 07 Dec '00

07 Dec '00

Folks, In H.225.0v4, there are several references to the Global Call Reference value. It is described in H.323v4 how it is used for Facility to signal changes in the "multipleCalls" state and in IRQ to indicate a request for information for all calls. However, what is the use for it in Status and Status Inquiry? Also, for the Facility message, how shall the CallIdentifier be coded, since the Facility-UUIE is now required? Paul

2 2

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