- sg16-avd - lists.packetizer.com

MGCP interop
by ajays 05 Oct '00

05 Oct '00

Hello! I wanted to know, when the next MGCP interop is going to be and where can I find information on it ? Regards Ajay ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[H.323 Mobility:] Draft H.235 Annex G - "Security for H.323 Mobil e Environments" uploaded
by Euchner Martin 05 Oct '00

05 Oct '00

Hi all, you may find the uploaded draft MD-109 at the following URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-109.zip <ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/MD-109.zip> This is the initial draft of new H.235v3 Annex G. The draft has been created from Portland APC-1937. The authentication and key management procedures may be accomplished either during GK discovery or during registration phase. The draft provides also some more detailed security procedures. With kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Q.931 package for MGCP?
by Rosen, Brian 05 Oct '00

05 Oct '00

This might be the wrong email list for this kind of question. The MGCP list at the Softswitch Consortium ( www.softswitch.org <http://www.softswitch.org> ) or at pulver.com would be more appropriate. The answer is -- wrong idea. MGCP is a device control protocol, not a signalling protocol. You wouldn't try to map Q.931 to MGCP except some simplistic notions of connections. This would be local to a particular softswitch implementation, and thus not standardized. You can ask how the Q.931 gets from the gateway to the softswitch. It isn't over MGCP! Generally, the accepted notion is that the MG terminates Q.921, and uses SCTP and IUA to transport Q.931 to the Call Agent, which terminates the Q.931 messages, creating the appropriate MGCP commands to make the right connections. The Call Agent might have to map Q.931 to whatever protocol it uses to connect to another Call Agent. That might be ISUP (Q.BICC to be exact), H.323, or SIP. Brian -----Original Message----- From: Jeff Jenkins [mailto:jjenkins@jetstream.com] Sent: Wednesday, October 04, 2000 6:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Q.931 package for MGCP? Anyone aware of a Q.931 package for MGCP? I am interested in mapping Q.931 to MGCP. -- jrj

1 0

Re: MGCP interop
by Rosen, Brian 05 Oct '00

05 Oct '00

There are several possible answers to this: 1. The PacketCable folks have a schedule for testing that includes their MGCP profiles 2. The ISC will sponsor MGCP testing "soon". We (the ISC) are working out exactly how to do that. I'd say we will have an ISC sponsored MGCP test within the next 4-6 months. Brian > -----Original Message----- > From: ajays [mailto:ajays@miel.mot.com] > Sent: Thursday, October 05, 2000 6:25 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: MGCP interop > > > Hello! > > I wanted to know, when the next MGCP interop is going > to be and where can > I find information on it ? > > Regards > Ajay > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Q.931 package for MGCP?
by Jeff Jenkins 04 Oct '00

04 Oct '00

Anyone aware of a Q.931 package for MGCP? I am interested in mapping Q.931 to MGCP. -- jrj

1 0

PCS2001 Final Call for Papers
by ȣ�伺 03 Oct '00

03 Oct '00

Please find attached Final Call for Papers of Picture Coding Symposium 2001 to be held in Seoul, Korea during 25 April - 27 April, 2001. The deadline for paper submission, 15 October 2000, is coming soon. Updated paper submissioin information is at http://pcs.kaist.ac.kr. For further information, please send an email to pcs(a)pcs.kaist.ac.kr. We look forward to seeing you at the exciting PCS2001. Best Regards, Yo-Sung Ho ********************************************************** Yo-Sung Ho, Associate Professor Department of Information and Communications Kwang-Ju Institute of Science and Technology (K-JIST) 1 Oryong-Dong Puk-Gu Kwangju, 500-712, Korea TEL: +82-62-970-2211 FAX: +82-62-970-2204 EMAIL: hoyo(a)kjist.ac.kr **********************************************************

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 03 Oct '00

03 Oct '00

Hi, Everyone: The bottom line is that H.323 Annex H has done its own job. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times): Part 1: Within the scope of Q.13/16: Extension of H.323(e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.(Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.). It has done something that it MUST not do in the first place (exceeding the mandate Q.13/16). I am in full agreement with Dr. Jean-Claude Samou of France Telecom. AT&T is also planning to bring contributions in WP2/16 in the upcoming SG meeting (Nov'00). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Tuesday, October 03, 2000 9:27 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi all, Maybe I should first clear up a potential misunderstanding. I don't think anyone in the Mobility ad hoc group is trying to avoid taking the work done in IMT-2000 or 3GPP into account. In fact we have used the IMT-2000 specification in our work already quite a lot (it is not a coincidence that the requirements, etc. are so similar between H.323 Annex H and IMT-2000) and definitely we would like to follow the IMT-2000 framework as much as we see possible (further co-operation and meetings would certainly be a positive thing). Also I am currently working on making the terminology of Annex H to correspond better to the 3GPP terminology as was requested in the Portland meeting. Furthermore, one of my intentions when encouraging people to come up with contributions for the Mobility Management procedures (information flows) of the annex has been to get propositions that might be better in line with especially the 3GPP work. Unfortunately I feel that I myself am not yet enough of an expert in 3GPP issues to be able to do that. However, I think the general feeling in the ad hoc group has been that the 3GPP and IMT-2000 specifications on the Mobility Management procedures will still take quite long before being ready. Another issue that has been raised is the question of possible (or probable) unnecessary complexity of the coming 3G Mobility Management protocols for enterprise usage. Thus a need to specify simple procedures for the Mobility Management quite quickly for H.323 has been recognized and this would also necessitate the definition of protocols or specifying how existing protocols would be used between the VLFs and HLFs for instance. In the absense of propositions to use other existing or future protocols, the annex draft at the moment suggests the usage of somewhat altered H.225 Annex G protocol as the Mobility Management protocol to be used between the GKs, VLFs, HLFs and AuFs (I think we should also limit the interfaces we are defining for the first version of the annex to perhaps just handle the VLF-HLF communications...). The good thing about this approach would, at least, be the easy addition to already existing H.323 systems because of the usage of existing (albeit slightly altered) H.323 family protocol. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ > Hi, Everyone: > > Sorry for not getting into the discussion earlier since I was > out of station > for some time. I just logged into my PC and saw your > interesting e-mail > discussion on mobility management protocols (in particular > between the VLF > and HLF). > > I would like to share here some concerns of Radhika Roy on > this matter. As > he clearly points out, the HLF and VLF are only value-added > functions which > are necessary for handling mobility of users. There is > nothing specific in > VLF <-> HLF in terms of mobility with respect packet vs. circuit or > connection oriented vs connectionless, etc. > > As you are probably aware of, the IMT-2000 group in ITU-T > SG11 is currently > working on developing a common mobility management protocol > which should > accomodate various users of different types of mobile systems > (e.g. IS-41, > UMTS, etc). This is the well known FAMILY concept in ITU-T > SG11. SG16 and > SG11 had one joint meeting in the last Feb'00 in Geneva. During this > meeting, this mobility protocol work was briefly introduced > by SG 11 and it > was recognized that the requirements & major concepts identified for > mobility in H.323 networks are very similar to those of > IMT-2000 (since > IMT-2000 should also provide packet-based multi-media > services), and a close > cooperation between these two groups is required on mobility > and roaming > aspects for the benefits of H.323 and IMT-2000 systems. In > addition, this > will allow the roaming of any users between different types > of network (for > instance an H.323 user roaming into an IS-41 or UMTS network and > vice-versa). Therefore, I tend to disagree with Jaakko who says that > IMT-2000 is not defining (or intended for) packet-based networks. For > instance the concept of VLF and HLF are pretty much close to > those of the > LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the > strict reason that > they are both server functions which handle mobility > independently of the > transport networks. Then why not a common protocol for common mobility > requirements and functions? On the other hand, I agree that > Extensions of > H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be > provided by Q.13/16 > since they are very specific to the H.323 type of access. > > Again, I would like to support Radhika in his analysis of > trying to develop > a common solution that fits the need of any type of mobile > users rather than > developing one VLF <-> HLF protocol for H.323, one VLF <-> > HLF for H.321, > etc. Otherwise, it will be a BIG mess for network operators > (as well for > manufacturers) and lead to have different protocols which may be > incompatible between themselves. This will also make the > inter-networking > aspects very tough thereby preventing any global roaming of users. > > FYI, I would also like to inform you that 3GPP has selected > SIP for its > MULTIMEDIA stuff. In this case, how would it be possible to > roam between a > 3GPP network and H.323 network, and with other networks (not using > SIP)unless an inter-connecting pipe such as a common MM > protocol (which > includes SIP mobility, H.323 mobility, IS-41 mobility, etc) > is developed. > > Therefore, I would suggest that we should rather work with a > more global > picture of ITU (as supported by Radhika) than a narrow one > limited to H.323 > mobility only. > > Let me be more positive now. I would really encourage SG16 and SG11 to > closely > cooperate together in order to develop this common protocol > jointly for the > success of ITU. I believe that this step has already started > at the joint > SG16-SG11 meeting in February 00. Why shoudn't this be continued? > > Best regards, > > Jean-Claude Samou, PhD > France Telecom R&D > 38-40, rue du General Leclerc > 92131 Issy les moulineaux > France > > Tel: + 33 1 45 29 58 40 > Fax: + 33 1 46 29 31 62 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Jaakko Sundquist 03 Oct '00

03 Oct '00

Hi all, Maybe I should first clear up a potential misunderstanding. I don't think anyone in the Mobility ad hoc group is trying to avoid taking the work done in IMT-2000 or 3GPP into account. In fact we have used the IMT-2000 specification in our work already quite a lot (it is not a coincidence that the requirements, etc. are so similar between H.323 Annex H and IMT-2000) and definitely we would like to follow the IMT-2000 framework as much as we see possible (further co-operation and meetings would certainly be a positive thing). Also I am currently working on making the terminology of Annex H to correspond better to the 3GPP terminology as was requested in the Portland meeting. Furthermore, one of my intentions when encouraging people to come up with contributions for the Mobility Management procedures (information flows) of the annex has been to get propositions that might be better in line with especially the 3GPP work. Unfortunately I feel that I myself am not yet enough of an expert in 3GPP issues to be able to do that. However, I think the general feeling in the ad hoc group has been that the 3GPP and IMT-2000 specifications on the Mobility Management procedures will still take quite long before being ready. Another issue that has been raised is the question of possible (or probable) unnecessary complexity of the coming 3G Mobility Management protocols for enterprise usage. Thus a need to specify simple procedures for the Mobility Management quite quickly for H.323 has been recognized and this would also necessitate the definition of protocols or specifying how existing protocols would be used between the VLFs and HLFs for instance. In the absense of propositions to use other existing or future protocols, the annex draft at the moment suggests the usage of somewhat altered H.225 Annex G protocol as the Mobility Management protocol to be used between the GKs, VLFs, HLFs and AuFs (I think we should also limit the interfaces we are defining for the first version of the annex to perhaps just handle the VLF-HLF communications...). The good thing about this approach would, at least, be the easy addition to already existing H.323 systems because of the usage of existing (albeit slightly altered) H.323 family protocol. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ > Hi, Everyone: > > Sorry for not getting into the discussion earlier since I was > out of station > for some time. I just logged into my PC and saw your > interesting e-mail > discussion on mobility management protocols (in particular > between the VLF > and HLF). > > I would like to share here some concerns of Radhika Roy on > this matter. As > he clearly points out, the HLF and VLF are only value-added > functions which > are necessary for handling mobility of users. There is > nothing specific in > VLF <-> HLF in terms of mobility with respect packet vs. circuit or > connection oriented vs connectionless, etc. > > As you are probably aware of, the IMT-2000 group in ITU-T > SG11 is currently > working on developing a common mobility management protocol > which should > accomodate various users of different types of mobile systems > (e.g. IS-41, > UMTS, etc). This is the well known FAMILY concept in ITU-T > SG11. SG16 and > SG11 had one joint meeting in the last Feb'00 in Geneva. During this > meeting, this mobility protocol work was briefly introduced > by SG 11 and it > was recognized that the requirements & major concepts identified for > mobility in H.323 networks are very similar to those of > IMT-2000 (since > IMT-2000 should also provide packet-based multi-media > services), and a close > cooperation between these two groups is required on mobility > and roaming > aspects for the benefits of H.323 and IMT-2000 systems. In > addition, this > will allow the roaming of any users between different types > of network (for > instance an H.323 user roaming into an IS-41 or UMTS network and > vice-versa). Therefore, I tend to disagree with Jaakko who says that > IMT-2000 is not defining (or intended for) packet-based networks. For > instance the concept of VLF and HLF are pretty much close to > those of the > LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the > strict reason that > they are both server functions which handle mobility > independently of the > transport networks. Then why not a common protocol for common mobility > requirements and functions? On the other hand, I agree that > Extensions of > H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be > provided by Q.13/16 > since they are very specific to the H.323 type of access. > > Again, I would like to support Radhika in his analysis of > trying to develop > a common solution that fits the need of any type of mobile > users rather than > developing one VLF <-> HLF protocol for H.323, one VLF <-> > HLF for H.321, > etc. Otherwise, it will be a BIG mess for network operators > (as well for > manufacturers) and lead to have different protocols which may be > incompatible between themselves. This will also make the > inter-networking > aspects very tough thereby preventing any global roaming of users. > > FYI, I would also like to inform you that 3GPP has selected > SIP for its > MULTIMEDIA stuff. In this case, how would it be possible to > roam between a > 3GPP network and H.323 network, and with other networks (not using > SIP)unless an inter-connecting pipe such as a common MM > protocol (which > includes SIP mobility, H.323 mobility, IS-41 mobility, etc) > is developed. > > Therefore, I would suggest that we should rather work with a > more global > picture of ITU (as supported by Radhika) than a narrow one > limited to H.323 > mobility only. > > Let me be more positive now. I would really encourage SG16 and SG11 to > closely > cooperate together in order to develop this common protocol > jointly for the > success of ITU. I believe that this step has already started > at the joint > SG16-SG11 meeting in February 00. Why shoudn't this be continued? > > Best regards, > > Jean-Claude Samou, PhD > France Telecom R&D > 38-40, rue du General Leclerc > 92131 Issy les moulineaux > France > > Tel: + 33 1 45 29 58 40 > Fax: + 33 1 46 29 31 62 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

iptel2001 Call for Papers
by Jiri Kuthan 02 Oct '00

02 Oct '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 November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 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 K. Mehdi University of Kansas 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. Stüttgen 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

PV2001 Final Call for Papers
by PV2001 25 Sep '00

25 Sep '00

Please find attached Final Call for Papers of Packet Video Workshop 2001 to be held in Kyungju, Korea During 30 April - 1 May, 2001. The deadline for paper submission, 15 November 2000, is coming soon. Updated paper submissioin information is at http://pv2001.kaist.ac.kr. For further information, please send an email to pv(a)pv2001.kaist.ac.kr. We look forward to an exciting PV2001. Best Regards, Chieteuk Ahn PV2001 Organizing Committee Chair

1 0