- sg16-avd - lists.packetizer.com

q11h17, apc1457
by Yoshihiro Kikuchi 11 Nov '98

11 Nov '98

Dear Q.11 and Q.14 experts, Ihave place the following document to the dropbox q11-site/dropbox (avc-site/incoming) directory: Q11-H-17 (APC-1457) Proposed Changes on H.245 Codepoints for MPEG-4 Visual Support (Proposal) Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku(a)eel.rdc.toshiba.co.jp Research and Development Center TEL: +81 +44 549 2151 Toshiba Corp. FAX: +81 +44 520 1308

1 0

Final reminder for the Torino meeting
by Sakae OKUBO 10 Nov '98

10 Nov '98

Dear Q.12-14/16 experts, Q.12-14/16 are going to meet jointly with Q.11/16 in Torino during 17-20 November 1998. The meeting notice is found at: ftp://standard.pictel.com/avc-site/9811_Tor/Notice_Torino.txt or http://standard.pictel.com/ftp/avc-site/9811_Tor/Notice_Torino.txt Important dates are: 1. Registration of participation Advise Donatella Bertolotti (donatella.bertolotti(a)cselt.it) with copy to three Rapporteurs (e-mail: okubo(a)giti.or.jp, Dale.Skran(a)ascend.com, gthom(a)delta-… [View More]info.com) by 10 November. 2. Registration of the document Advise Sakae Okubo (okubo(a)giti.or.jp) by 6 November (already gone). In case your contribution is not included in the attached list, please promptly advise S Okubo. 3. Distribution of the document Upload to ftp://standard.pictel.com/avc-site/Incoming by 10 November. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations 1463 KPN H.450.Call Completion on Busy Subscriber 1464 Ericsson New code point, for T.140, in H.224 1465 Nortel Connection Model For Device Control 1466 Nortel Requirements For The Device Control Interface 1467 Nortel Requirements For SCN-H.323 Signalling Interworking 1468 Siemens Report about ETSI TIPHON meeting of October 26-30, Tel Aviv 1469 Madge Networks Scalable security for Annex G 1470 BT Requirements for IVR Control in VoIP 1471 VideoServer ISUP and FAS/NFAS Call Signaling for H.323 Gateways 1472 Editor H.225.0 V3 current draft 1473 Editor H.225.0 Annex G working draft 1474 Lucent Technologies SS7 Information Transport over Intermediate H.323 Network 1475 Lucent Technologies Comments on Annex G 1476 ITXC, VocalTec, and Lucent Technologies Interoperability Profile ----------------------------------------------------------------------- [View Less]

2 1

Re: CAS backhaul - Why backhaul
by Hluchyj, Mike 10 Nov '98

10 Nov '98

Ray has raised some excellent points that address some fundamental issues worthy of careful consideration. There seems to be a basic, underlying assumption that the centralization of all gateway control provides the most cost-effective, scaleable and flexible solution to the building of media gateways. In my opinion, this moves the pendulum too far and doesn't take advantage of a number of important technical lessons learned over the past few decades. There has been a natural evolution in … [View More]communications equipment architectures to distribute the workload among multiple processing elements as a means of achieving scalability. In particular, the trend has been to centralize "global" functions while distributing "local" functions. We have seen this trend on the data side with centralized routing and forwarding being replaced by centralized route computation and distributed (among the line cards) forwarding. We have seen it in the circuit-switching world with signaling and, in some cases, call control functions being distributed among the line cards supporting the corresponding bearer channels. This approach of distributing purely local functions provides a natural system scaling - add more line cards, get more processing with inexpensive, low-end processors. Furthermore, there is no compelling reason to keep all of the detailed state information for all end points in one place - the switch creates connections among end points and end points which are not connected do not need to share state information. In fact, on a truly global scale, this distributed processing model is what has allowed us to build worldwide telephony and IP networks. The principles of distributed processing at a network level work equally well in building scaleable switching and media processing. So, how does this principle apply to our current situation? In order to answer this question, we have to understand what we are trying to accomplish. Specifically, carriers/service providers would like to be able to rapidly deliver services on a large scale using hardware and software from multiple suppliers (hence the need for open interfaces and interoperability). The separation of the media controller (MC) from the media gateway (MG) seems to be a basic tenet of how this should be accomplished, and I have no fundamental disagreement with this. However, I believe that we have placed too much functionality in the MG and that this may work against the scalability. In particular, with the exception of SS7 (which I'll address later), signaling is a function that can and should be distributed among the line cards. When one configures a line or a trunk on the PSTN side, inherently each end of the line/trunk is configured for the bearer channel and the associated signaling protocol that both ends understand. Basic to the signaling is the ability to collect address (i.e., the dialed number) and other information for incoming calls. Basic to CAS and ISDN interfaces are protocol state machines to handle all this routine processing. This first stage of processing does not vary from call to call - it's configured so that each side can understand the other. The interesting stuff comes after this initial information is collected, and this is where an external control function like the MC can play a significant and important role. What makes a gateway "dumb" should not be the lack of signaling stacks or even call state, but rather what to do with a call when it arrives to the gateway. Each arriving call should trigger a message to the MC that basically says "here's the information that I collected for this arriving call, what should I do?" The MC may determine that it is a simple tandem call for which the MC will perhaps do some authorization on the calling number and then determine a route (by maybe consulting a gatekeeper or other backend function). Alternatively, based on the information collected by the signaling function, the MC may determine that it's a calling card call and requires a second stage of dialing. Whether tandem, calling card or other service, the response to the MG is a script (or some form of call processing instructions) from the MC that tells the MG how to process the call. In this way, the MG is "dumb" with respect to how to process each arriving call, yet assumes the signaling and call processing burden that is most cost-effectively performed by processors in the MG. The MC is now more of a pure IT environment with lots of transaction processing and database queries best suited for a general purpose computing environment. New services can be introduced by developing new scripts. Now what about SS7? I think that early thinking on how SS7 can be used for providing PSTN interconnection for ISP remote access servers via IMTs led to the current trend of piling lots of signaling and call processing into the MCs. As many others have convincingly argued, it makes much sense to terminate SS7 A and F links on an external signaling gateway (to preserve scare SS7 point codes, to allow one to separate a significant and complex development with many country variations and certification requirements into a separate component, etc.) But an ISUP IAM message signifying an incoming call for a particular CIC (DS0 on a trunk group) can just as easily be processed by a processor on the trunk card that supports that DS0 (as though the signaling arrived via CAS or ISDN). This then makes it consistent with how CAS and ISDN trunks are served per the above discussion. This approach seems to lead to a scaleable decomposition of the problem. Carriers are free to choose best-in-class components including: MGs with appropriate cost/performance/scaleablity/reliablity tradeoffs, service creation environments (for creating the standards- based scripts), MC for providing the intelligence to determine services and route calls, and SS7 gateways for dealing with the complex and varying legacy in PSTN signaling. As always, vendors are free to group components together. But if we don't carefully select the appropriate model of decomposition, then service providers may be needlessly locked into vendor relations because of the close and hidden coupling of what could have been separable components. This includes the close and hidden coupling of software elements within the MC based on the current thinking. Mike Hluchyj Sonus Networks, Inc. 5 Carlisle Road Westford, MA 01886 USA phone: +1-978-692-8999 x227 fax: +1-978-392-9118 email: mhluchyj(a)sonusnet.com -----Original Message----- From: Graham, Gregory [RICH6:B917-M:EXCH] [mailto:ggraham@americasm01.nt.com] Sent: Thursday, November 05, 1998 8:32 PM To: sigtran(a)BayNetworks.COM Subject: RE: CAS backhaul - Why backhaul Ray, It is true that if ISUP and Q.931 signaling is backhauled to the MC, the software on the MC will be complex, but it is better to have the complex software run on a computer that is separate from the gateway devices. You want the complex software to run on off-the-shelf computing equipment where processing power is inexpensive and scalable. Keep the special purpose gateway equipment as simple as possible. I do agree that you want some layering in your call processing software to separate protocol specific processing from higher-level service logic, but I prefer both layers to run on the MC rather than splitting them between the MG and MC and having to standardizing a protocol between them. Greg Graham ggraham(a)nortel.com (972) 684-5218 > -----Original Message----- > From: Zibman, Ray [SMTP:izibman@gte.com] > Sent: Tuesday, November 03, 1998 8:22 AM > To: 'David R. Oran'; Mauricio Arango; 'Christian Huitema' > Cc: sgcp(a)bellcore.com; sigtran(a)BayNetworks.COM > Subject: RE: CAS backhaul - Why backhaul > > I agree that if the call agent (MC) really needs all the rich call state > semantics present in Q.931 then the easiest approach is to backhaul the > whole thing. What I haven't seen is much discussion of the premise of > this > proposition. What does the call agent need to do its mission? What is > its > mission? If there are pointers to good discussion on this topic already, > please point me. > > These questions are equally relevant to backhaul from an SS7 SG to the MC. > If we our goal is to build any variety of full-featured end office or > tandem > switch out of SGs, MGs, and MCs then we need to get to (and from) the MC > every bit of information out of any protocol used for control signaling. > A > more modest and possibly more achievable goal is to try to characterize > the > kind of call control scenarios we want the MC to deal with. Then we could > define some relevant abstractions of call state and determine what > information reduction can take place inside an SG (or the equivalent part > of > an MG for CAS, ISDN, ...) so that the call agent gets and sends what is > relevant and the MC is protected from the irrelevant. I worry about the > complexity of call agent based service logic that needs to deal these very > rich protocols. I expect that if we don't do the information reduction in > the SG or MG that it will take place anyway in some layer of the call > agent > before the information reaches service logic, but service interoperability > (e.g. feature interactions, portability) will suffer. > > Intelligent Network reduced the several thousand states of a modern switch > to call models with between 2 to 32 points in call. It is recognized that > the simpler call models do not support all the services of a class 5 > switch, > but they support enough to be useful to service developers for a large, > but > limited set of services. (I don't suggest using an Intelligent Network > call > model for a IP-based service model. I think there are differences in > requirements.) > > Let's define the mission for a call agent and the reasons for backhaul > before trying to define the details. > > ------------------------------------------- > Ray Zibman GTE Laboratories Incorporated > Senior Technologist 40 Sylvan Road > Office: (781) 466-2291 Waltham, MA 02454 > Fax: (781) 890 9320 <mailto:izibman@gte.com> > > [View Less]

1 0

Contribution APC-1456
by Yair Miranda 10 Nov '98

10 Nov '98

Dear Mr.Okubo, I have uploaded APC-1456.zip into the incoming directory. Best regards, Yair Miranda yair(a)radvision.rad.co.il Tel : +972-3-6455271 Fax : +972-3-6476669 Video : +972-3-6489010 http://www.radvision.com

1 0

Re: Document number assignment
by Sakae OKUBO 10 Nov '98

10 Nov '98

Dear Mr. Ott, > could you please assign a document number to Draft H.323 Annex F > Single Use Devices. On an exceptional basis, APC-1479 has been allocated to your contribution as attached. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +… [View More]81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations 1463 KPN H.450.Call Completion on Busy Subscriber 1464 Ericsson New code point, for T.140, in H.224 1465 Nortel Connection Model For Device Control 1466 Nortel Requirements For The Device Control Interface 1467 Nortel Requirements For SCN-H.323 Signalling Interworking 1468 Siemens Report about ETSI TIPHON meeting of October 26-30, Tel Aviv 1469 Madge Networks Scalable security for Annex G 1470 BT Requirements for IVR Control in VoIP 1471 VideoServer ISUP and FAS/NFAS Call Signaling for H.323 Gateways 1472 Editor H.225.0 V3 current draft 1473 Editor H.225.0 Annex G working draft 1474 Lucent Technologies SS7 Information Transport over Intermediate H.323 Network 1475 Lucent Technologies Comments on Annex G 1476 ITXC, VocalTec, and Lucent Technologies Interoperability Profile 1477 Q12 Rapp. Plan for H.321 Implementors Guide 1478 ATMF H.323 media transport over ATM 1479 Editor Draft H.323 Annex F Single Use Devices ----------------------------------------------------------------------- [View Less]

1 0

H.245 alphanumeric support required?
by Rich Bowen 10 Nov '98

10 Nov '98

Hello experts, H.323 v2 section 6.8.2.1 says, "Transmitters shall limit the content of their transmitted information to that which the receiver has indicated it is capable of receiving." On the other hand, H.245 v3 section 7.12.6 says, "Endpoints shall use the alphanumeric indication to convey DTMF user input if the other endpoint has not indicated the ability to receive DTMF using UserInputCapability." These two statements seem to be in conflict since H.245 v3 seems to be saying that the … [View More]

1 0

Contribution APC-1468
by Meyer Gerald 10 Nov '98

10 Nov '98

Dear Mr.Okubo, I have uploaded APC-1468.zip into the incoming directory. Best regards, Gerald Meyer --------- gerald.meyer(a)icn.siemens.de T: +49 89 722-24039 F: +49 89 722-62366

1 0

Contribution Q11-H-11 and APC 1453
by Antony Crossman 10 Nov '98

10 Nov '98

Contribution Q11-H-11, also APC 1453, has been uploaded to lbc-site/dropbox and avc-site/incoming. Contribution title "Requirements for layered audio coding". ------------------------------------------------------------------------- Antony Crossman PictureTel Corporation, 100 Minuteman Road, Andover, MA 01810-1031, USA Tel. +1 (978) 623 4557 Fax: +1 (978) 749 2804 email: tonyc(a)pictel.com -------------------------------------------------------------------------

1 0

APC-1460
by Takashi SUZUKI 10 Nov '98

10 Nov '98

Dear Mr.Okubo, I have uploaded APC-1460.zip into the incoming directory. Best regards, Takashi Suzuki --------- Takashi Suzuki@NTT DoCoMo Tel:+81468 40 3520 / Fax:+81 468 40 3788

1 0

Nearly final list of documents and APC-1426
by Sakae OKUBO 10 Nov '98

10 Nov '98

Dear Q.12-14/16 experts, Attached please find the nearly final list of documents for the Torino meeting. I have taken my advantage to include APC-1477. APC-1426 was input from India to the SG16 meeting last September, but it reached ITU-TSB very late, thus forwarded to the Rapporteur meeting. Though I requested the submitter to provide an electronic copy, it has not been successful. A hardcopy document will be distributed in Torino. As a last resort, I have scanned the fax copy I got in … [View More]Geneva and placed it at the ftp site as /9811_Tor/APC-1426.zip. This will be extracted to ten files each of which containing a page of 300 KB size JPEG picture. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations 1463 KPN H.450.Call Completion on Busy Subscriber 1464 Ericsson New code point, for T.140, in H.224 1465 Nortel Connection Model For Device Control 1466 Nortel Requirements For The Device Control Interface 1467 Nortel Requirements For SCN-H.323 Signalling Interworking 1468 Siemens Report about ETSI TIPHON meeting of October 26-30, Tel Aviv 1469 Madge Networks Scalable security for Annex G 1470 BT Requirements for IVR Control in VoIP 1471 VideoServer ISUP and FAS/NFAS Call Signaling for H.323 Gateways 1472 Editor H.225.0 V3 current draft 1473 Editor H.225.0 Annex G working draft 1474 Lucent Technologies SS7 Information Transport over Intermediate H.323 Network 1475 Lucent Technologies Comments on Annex G 1476 ITXC, VocalTec, and Lucent Technologies Interoperability Profile 1477 Q12 Rapp. Plan for H.321 Implementors Guide 1478 ATMF H.323 media transport over ATM ----------------------------------------------------------------------- [View Less]

1 0

Registration of the Torino meeting
by Sakae OKUBO 10 Nov '98

10 Nov '98

Dear Q.11-14/16 experts, I hope you have received a file named <<SG16 November '98 meeting.doc>> from the meeting host. If you are going to attend the next week meeting, but not listed there, or listed with incorrect information, please advise Bertolotti Donatella <Donatella.Bertolotti(a)CSELT.IT>. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th … [View More]

1 0

Participants Torino meeting
by Bertolotti Donatella 10 Nov '98

10 Nov '98

<<SG16 November '98 meeting.doc>>

1 0

Re: APC 1429 (H.323 Version 2 Compliant Profile)
by Kumar, Vineet 09 Nov '98

09 Nov '98

Espen, The goals of APC-1429 are: (1) Provide guidance to the implementer on features of H.323 to implement. Since H.323 is feature-rich, it is important that there should be a basic profile. (2) Provide guidance to the implementer on how to fill the fields in the required messages so that interoperability among implementations is easier to achieve. Regards, vineet kumar > -----Original Message----- > From: Espen Skjæran [SMTP:Espen.Skjaeran@ERICSSON.COM] > Sent: Monday, November … [View More]

1 0

Communication from ATMF re H.323 over ATM
by Sakae OKUBO 09 Nov '98

09 Nov '98

Dear Q.12-14/16 experts, I have uploaded the attached communication from ATMF as APC-1478. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** … [View More]

1 0

Document uploaded
by Callaghan, Robert 09 Nov '98

09 Nov '98

The following documents have been uploaded to the incoming directory: Apc-1446 Apc-1447 ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0

APC 1429 uploaded to the Incoming directory of the avc-site
by Kumar, Vineet 09 Nov '98

09 Nov '98

Dear Colleagues: APC 1429 (H.323 Version 2 Compliant Profile) has been uploaded as apc-1429.zip to the Incoming directory of the avc-site. Regards, vineet ---------------------------------------------------------------------------- -------------------------- Vineet Kumar vineet.kumar(a)intel.com Intel Corporation, JF3-212 (+1) 503-264-3439 (phone) Hillsboro, OR 97124-5961 (+1) 503-264-3375 (fax) ---------------------------------------------------------------------------- --------------------------

2 1

APC's 1431 and 1433
by Kaynam Hedayat 08 Nov '98

08 Nov '98

Dear Mr. Okubo, I have uploaded APC numbers 1431 and 1433 into the incoming directory. Regards, Mr. Kaynam Hedayat

1 0

APC number allocation
by Sakae OKUBO 07 Nov '98

07 Nov '98

Dear Mr. Freudlich, In response to your request, APC-1472 to 1476 have been allocated to your contributions as attached. Many apologies for your inconvenience due to my mailbox trouble last Friday. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +… [View More]81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations 1463 KPN H.450.Call Completion on Busy Subscriber 1464 Ericsson New code point, for T.140, in H.224 1465 Nortel Connection Model For Device Control 1466 Nortel Requirements For The Device Control Interface 1467 Nortel Requirements For SCN-H.323 Signalling Interworking 1468 Siemens Report about ETSI TIPHON meeting of October 26-30, Tel Aviv 1469 Madge Networks Scalable security for Annex G 1470 BT Requirements for IVR Control in VoIP 1471 VideoServer ISUP and FAS/NFAS Call Signaling for H.323 Gateways 1472 Editor H.225.0 V3 current draft 1473 Editor H.225.0 Annex G working draft 1474 Lucent Technologies SS7 Information Transport over Intermediate H.323 Network 1475 Lucent Technologies Comments on Annex G 1476 ITXC, VocalTec, and Lucent Technologies Interoperability Profile ----------------------------------------------------------------------- [View Less]

1 0

Uploaded contributions
by Sakae OKUBO 07 Nov '98

07 Nov '98

Dear Q.12-14/16 experts, At presend the following contributions are available at ftp://standard.pictel.com/avc-site/9811_Tor/ or http://standard.pictel.com/ftp/avc-site/9811_Tor/ ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile … [View More]

1 0

Registration of the contributions
by Sakae OKUBO 06 Nov '98

06 Nov '98

Dear Jeroen de Muijnck, Mickey Nasiri, Tom Taylor, Gerald Meyer, Andrew Draper, Cordell, Bryan Hill, In response to your requests, APC numbers have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +… [View More]81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations 1463 KPN H.450.Call Completion on Busy Subscriber 1464 Ericsson New code point, for T.140, in H.224 1465 Nortel Connection Model For Device Control 1466 Nortel Requirements For The Device Control Interface 1467 Nortel Requirements For SCN-H.323 Signalling Interworking 1468 Siemens Report about ETSI TIPHON meeting of October 26-30, Tel Aviv 1469 Madge Networks Scalable security for Annex G 1470 BT Requirements for IVR Control in VoIP 1471 VideoServer ISUP and FAS/NFAS Call Signaling for H.323 Gateways ----------------------------------------------------------------------- [View Less]

1 0

gateway decomposition call minutes
by Bryan Hill 06 Nov '98

06 Nov '98

Colleagues, The second gateway decomposition audio call was held Tuesday 11/3 from 11AM to 1PM EST. The following companies were represented on the call AT&T, Dialogic, Ascend, 3COM, Telogy Networks, Bellcore, Lucent, RADVision, Nortel, PakNetx, BT, VideoServer, and others. Tom Taylor presented the TIPHON document 10td101r1 that discussed requirements for Interface A of the gateway decomposition model. The following issues were discussed. - Interface A will be limited to media … [View More]control only, but events such as DTMF tones or call authorization occur can occur which are relevant to call signaling. A position was stated that when call signaling information is carried in-band form the SCN side, the media gateway component will need to recognize these events and report them to the control gateway component. It will be the control component of the gateway that will act on this information. After some time the discussions were halted and can revisited in Torino. - Management of media gateway resources was discussed. It was pointed out that similar resource management debate for revision 2.0 was a lengthy late night session that resulted in a very limited solution to the problem. The scope of our current discussion is to accommodate voice which makes the resource management problem much more straightforward. A concern was raised that agreeing to a short sighted voice solution that cannot be extended in the future is a bad thing and needs to be avoided. - The load balancing and hot stand-by capabilities common among of SS7 equipment was raised was raised as a requirement for the gateway. There was considerable discussion regarding the definition of these terms and the requirements for such functionality centering around whether this is a problem to solve with protocol or implementation. - A discussion regarding the applicability of using IETFs MGCP work for interface A was raised. The MGCP work was considered premature and not ready for use by the ITU-T. Considerable discussion regarding the desirability to leverage the IETFs work occurred and many agreed that the ITU and IETF should make every effort to arrive at complementary solutions to this problem. The discussion shifted to the B, C and D interface and Mr Sijben presented another TIPHON document 10td91. This document that presented the merits of mapping H.225 messages to ISUP messages. If further stated that H.225 facility UUIEs could be used to transport ISUP (or QSIG) messages, that are not applicable to H.225 messages, through the H.323 network. A proposal for abstracting the ISUP and H.225 and creating an abstract protocol was raised. Another proposals for using UDP to tunnel SS7 through the H.323 network was were suggested but due to time restraints the latter two options were not discussed in much detail. The proponents of these techniques agreed to submit these as APC to the November meeting in Torino. In closing there was some discussion about trying to hold a third call prior to the Torino meeting, but the group decided there was not sufficient time to hold such a meeting. Best Regards, Bryan Hill _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 bhill(a)videoserver.com <mailto:bhill@videoserver.com> [View Less]

1 0

Contribution Numbers Requested
by Tom-PT Taylor 06 Nov '98

06 Nov '98

Could I please have APC numbers for three contributions: Connection Model For Device Control Requirements For The Device Control Interface Requirements For SCN-H.323 Signalling Interworking Tom Taylor E-mail: taylor(a)nortel.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

Documents for the Q.12-14/16 Torino meeting
by Sakae OKUBO 06 Nov '98

06 Nov '98

Dear all contributors, Attached please find the list of registered documents for the Torino meeting as of 19:30 (Tokyo time) Friday. As I lost some mails in the morning today due to spool overload at our site, please carefully check the list and advise me if your contribution is missing there. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda … [View More]Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Torino meeting (17-20 November 1998) ----------------------------------------------------------------------- APC- Source Provisional title ----------------------------------------------------------------------- 1426 India Internet traffic on the PSTN 1427 Korea Telecom Required functions of RTP receiver and packet forwarding procedure for Dynamic Multicast Network 1428 Accord Video Telecommunication RTP Maximum Packet size 1429 Intel H.323 version 2 compliant Profile 1430 Editor Draft H.283 1431 PictureTel Changes to draft H.323 related to recommendations H.282 and H.283 1432 PictureTel H.283 and H.323 Annex E harmonization 1433 PictureTel General comments on Annex E 1434 AT&T Intra-Domain/Inter-Zone Gatekeeper-to-Gatekeeper and Inter-Domain Border Element-to-Border Element Communications for Distributive, Centralized, and Hybrid Architecture 1435 AT&T Viewgraph Presentation of the contribution described in APC1434 1436 RADVision Master-Slave Determination Procedure in GK routed call model 1437 Editor Update to Draft Recommendation H.341 1438 ETSI TIPHON Liaison from ETSI TIPHON transmitting the draft Phase 1 and 2 TIPHON architecture (DTS/TIPHON-02002) 1439 ETSI TIPHON Liaison from ETSI TIPHON regarding transport of ISUP in an H.323 network 1440 Intel New H.245 Messages for Bit-rate Management 1441 (G Kimchi) 1442 (G Kimchi) 1443 (G Kimchi) 1444 (G Kimchi) 1445 Siemens and Videoserver Conference out of consultation 1446 Siemens Tunnel Transport of SCN Signaling Protocols 1447 Siemens Comments on H.225 Annex G working draft 1448 Intel Coding and usage details for Annex G 1449 Q14 Rapp. New Question of SG15 on PSTN to Internet gateway 1450 MPEG Liaison to Q.12/16 1451 Q12 Rapp. Correction of Amendment 5 to ITU-T Rec. H.222.0| ISO/IEC 13818-1 1452 Q12 Rapp. Integrated edition of ITU-T Rec. H.222.0|ISO/IEC 13818-1 and ITU-T Rec. H.262|ISO/IEC 13818-2 1453 PictureTel Requirements For Layered Audio Coding 1454 Editor Draft H.450.7 1455 RADVision Comments on GK to GK communication protocol 1456 RADVision Tunneling of H.281/H.224 FECC frames 1457 Toshiba Proposed changes on H.245 codepoints for MPEG-4 visual support 1458 TAO Requirements for the H.32L system 1459 TAO Transmission efficiency, packetization delay and information rate 1460 NTT DoCoMo Multimedia terminal on IMT-2000 network 1461 Bellcore Media Gateway Control Protocol (MGCP) 1462 COMSAT Support of non-ITU voice codecs in ITU-T Recommendations ----------------------------------------------------------------------- [View Less]

2 1

Re: KPN contribution to Torino meeting
by Sakae OKUBO 06 Nov '98

06 Nov '98

Dear Jeroen de Muijnck, > please add to the list a KPN contribution titled 'H.450.Call Completion on > Busy Subscriber'. It is APC-1463. Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

APC-1430 and APC-1432 uploaded
by Mark Duckworth 05 Nov '98

05 Nov '98

I uploaded the following: APC-1430.zip H.283 - Remote Device Control Logical Channel Transport - Draft C APC-1432.zip H.283 and H.323 Annex E Harmonization to ftp://standard.pictel.com/avc-site/Incoming/ Mark Duckworth PictureTel Corporation

1 0