November 1998 - sg16-avd - lists.packetizer.com

contribution to the ITU-T SG16 Q12-14/16 on H323/IN/TINA
by Martine.Lapierre＠ALCATEL.FR 14 Nov '98

14 Nov '98

Dear Sakae OKUBO, As Ameneh explained to you, we would like to discuss the attached contribution (itu.doc) at the next SG16 Q12-14/16 meeting. We realized today that is was not registered in your list, and feel very sorry for disturbing your preparation. We sincerly apologize for this very late presentation and will provide the copies on site. I am probably totally wrong with the contribution numbering (I understood that it could be 1444, but I am not sure if we got any confirmation). Can I insit on the fact that it is just a proposal for information and discussion, not more. We would be very happy to get some feed back on it. Gerald Roullet that will attend your 4 days meeting, could present quickly the concepts on the diagram attached (itu.ppt). Very best regards Martine Lapierre ---------------------------------------------------------------------- Vice President Products and Marketing Alcatel Switching Systems Division phone + 33 1 3077 0032 e-mail martine.lapierre(a)alcatel.com ----------------------------------------------------------------------

2 1

Uploaded apc -1448
by Jim Toga 13 Nov '98

13 Nov '98

All, I have uploaded APC-1448 to the 'Incoming' directory on the avc-site Regards, jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

Looking for v2 and v3 documents
by Michael Sung 13 Nov '98

13 Nov '98

Hi, Can someone tell me where can I download following documents? h.225 VERSION 2 ( is there a version 3 ? ) h.245 version 3 h.323 version 3 Thanks. Michael Sung >

2 1

APC-1475
by Glen Freundlich 13 Nov '98

13 Nov '98

Dear Mr. Okubo, I have uploaded APC-1475 to the avc ftp site. I apologize for my late delivery. Best Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

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

13 Nov '98

>>> > >>> > [Mike] 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. >>> > >>> [Carl] Yup, makes sence to have SS7 GWs. However I don't think that the >>> signalling should be sent to the MG first before passing it on to the MC >>> (which is what I believe is being suggested here and thus my comment). >>> Why transit the signalling through the MG when the SS7 GW could >>> send the signalling directly to the MC? If "routine processing" is >>> needed then we could have the SS7 GW perform this function prior to >>> communicating with the MC. As for scaleable decomposition, the MC >>> can still make use of the MGs to run scripts associated with individual >>> calls. As of course, the industry can always demand bigger and more >>> powerfull SS7 GWs. >>> >> [Nancy] I think the architecture needs to be flexible. Either the SS7 >> messages can be passed from the SG to the MG so that they become like >> end-point associated signalling and be treated just as the ISDN signalling >> is, OR the SS7 messages can go through the MC to the MG. The device control >> protocol should be able to handle both. If the signalling is associated with >> the endpoint in the MG, then the MC learns about it as an event notification >> to the MC from the MG. If the signalling comes directly to the MC from the >> SG, then it is the MC's job to tell the MG. > > > [Ike] Actually, the architecture is flexible if we are careful to > correctly name the components. In the case where a primary rate > interface ISDN line terminates at a MG, and signaling is backhauled > to an MC, then by my definition the the device which contains an MG also > contains an SG. > > Looking at it that way, the example you give above can be restated as > "Either the device containing the MG function can also contain an SG > function for receipt of SS7 messages which can then be backhauled to > an MC, OR the SS7 messages can arrive at an independent device > which contains only an SG function, and the SS7 signals can be > backhauled directly to an MC." > > When you state "The device control protocol should be able to handle > both", I'd rather state "the signaling transport protocol should > be able to handle both." That is...whether SS7 signals are backhauled > from an independent SG, or from a device which combines the functions > of the SG and the MG, then the same signaling transport protocol should > be employed. > > I don't see the reason to use the MGCP event notification mechanism > to deliver the equivalent of ISUP messages from an MG to an MC. > > Rules of thumb: > - If you have signaling in message form already, then > backhaul it from the SG function to the MC function (if > you have one) using the signaling transport protocol > - If you have inband signaling, it is really media events > which need to be left to the MC function to interpret. > Use MGCP event notifications to deliver it to the MC, > and let the MC figure out the meaning in a service context. > - Alternatively, if you have inband signaling and know > you are unlikely to want to apply alternative meanings to inband > signaling, then you have the option of translating the > signaling to a message oriented signaling (such as Q.931). > When you do that, you've created an SG function on the > device, and you should use the signaling transport protocol > to backhaul the resulting message oriented signaling protocol > to your MC. > > Regards, > Ike Elliott > Level 3 Communications [Mike] The answer to Carl's question of why does the SS7 GW send the signaling to the MG first instead of directly to the MC is that putting a component of call control in the MG will enhance the scalability of the decomposition. In the current thinking on the decomposition, all of the call control for a (potentially) large number of gateways would be located in the MC running on a general-purpose computing platform. As one adds lines/trunks to the MG or adds MGs to be served by a single MC, the compute power of the MC needs to grow accordingly. There are scalable, general-purpose computing platforms to which one can add processors and memory. But such platforms have limits and can be exceedingly expensive as they scale - particularly where redundancy is required. A better solution is to have some of the processing burden, the purely local component that has little need to communicate with other system elements, reside on the processing engines in the MG. This is a proven architecture for the kind of massive scalability that is required in carrier networks. I think that the call control function can be effectively divided between the MG and MC, so that call control processing (CCP) resides in the MG and call control information (CCI) resides in the MC. In this way, CCP is distributed throughout the MGs (e.g., on each trunk/line card), but the real intelligence on what to do with each call is derived from the CCI that resides in the centralized MC. One possible method that could be used by the CCI to tell the CCP what to do would be to use some type of scripting capability such as that proposed by Ike in draft-elliott-ipdc-media-00.txt. Using an approach like this, the call control script is run on the MG by CCP, but the actual script to be executed is determined by the MC through the CCI (which in turn is based on the services to which the customer has subscribed). Separating call control into CCP and CCI has the important benefit of distributing the call processing burden to achieve scalability. Still, the knowledge of subscribers, services and what to do with each call remains in the MC for ease of administration and control. The call processing flow then proceeds along these lines: ------- | CCI | MC ---|--- | | -----------------------|--------------------- | | | MG | CCP | | / \ | | / \ | --|->Ingress Signaling Egress Signaling--|--> | | ---------------------------------------------| 1) The ingress call signaling function (residing in MG for CAS and ISDN trunks/lines or on an external SS7 GW for SS7-based trunks) provides call indication and call parameters to the CCP in the MG. The call parameters, such as calling number, called number, trunk group of incoming call, carrier selection, etc., are obtained from the configured ingress signaling function. 2) CCP in the MG sends a request to the MC containing the call parameters for this call. 3) The MC determines the CCI for the call, including the script that the CCP should execute and, for simple (e.g., tandem) calls, the route (next GW or trunk group) that the call should follow. This is returned by the MC to the MG in its response to the request. 4) The CCP in the MG executes the script provided by CCI and, if the call is exiting the MG, invokes the egress signaling function associated with the selected outgoing path. In this way the signaling and CCP functions have a tight and well- defined relationship. The MC and MG have a simple request-response relationship. The MG contains no configured customer, services or call routing information, only the configuration of its links and other internal resources. All knowledge of what to do with a call is contained in the CCI residing in the MC and returned to the MG CCP in the form of scripts. New services are introduced by creating new scripts. There is no need to proportionally increase the size of the MC as the network grows. The MG takes on the burden of call processing. The MC is largely a database function that is easily replicated for redundancy and load sharing. A close parallel to this can be found in the evolution of carrier class circuit switching where the advent of microprocessor technology allowed more of the required call processing to be cost-effectively distributed first to remote switch modules and then to the individual line and trunk cards. Mike Hluchyj Sonus Networks

1 0

Re: H.235 Question
by Sengodan Senthil NRC/Boston 13 Nov '98

13 Nov '98

Object identifiers are yet to be assigned to algorithms within H.235. This issue also came up in the SG16 meeting in Geneva in September - but, none has been assigned yet. - Senthil ---------- From: Tom-PT Taylor To: ITU-SG16(a)mailbag.cps.intel.com Subject: FW: H.235 Question Date: Thursday, November 12, 1998 9:09PM I'm passing this one on to the list. > Hi Tom, > > I wonder if you could help me find some info. I want to implement some > security features in H.323 using H.235. My question is this: Do you know > if there are standard object identifiers already allocated for various > encryption algorithms? I presume there are, but I have no idea where to > find them. If there are can you point me in the right direction? > > Thanks in advance,

1 0

Re: Mechanisms for Extending H.225.0 without Adding to the Core Protocol
by Callaghan, Robert 13 Nov '98

13 Nov '98

Pete, I fully agree that this feature is needed. It is available _today_! The ability to transport standard and manufactures specific (proprietary) features is intrinsic to H.450.1. The term standard includes any ITU or ISO associated standards organization, including regional and national bodies. Using a small envelope, a user can place any information in any H.225.0 message. It includes call independent signaling. It includes the ability to address the message to a node in the call path. Since this service already exists, I do not see a need for a second implementation. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Pete Cordell [mailto:pete.cordell@BT-SYS.BT.CO.UK] Sent: Thursday, November 12, 1998 3:21 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Mechanisms for Extending H.225.0 without Adding to the Core Protocol Dear SG16 members, As usually I have been discussing requirements and uses for H.323 with different people within BT. What I find is they all need different additional features. This represents a problem for H.225, which could easily become as cumbersome as H.245! What is needed is a way to add feature to H.225 without having to add syntax to the core protocol each time. This issue has been particularly brought to a head with the issues relating to handling of SS7. I have therefore drafted a document that proposes a solution that will allow features to be added H.225 without having to continuously revise the core spec. So far I have only considered the Q.931 side of things, but the RAS side could also benefit from the same treatment. I have attached this document below for you to look at. The document gives more justification for why this issue urgently needs looking at, so I hope you will find the time to look at it. I know that this is too late as a contribution for this meeting, but I would be interested in discussing it with any interested parties in Torino so that something can be put together for the next meeting. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Documents APC-1480 and APC-1481 uploaded
by Douglas Clowes 13 Nov '98

13 Nov '98

Dear Mr. Okubo, I have placed APCs 1480, and 1481 into the Incoming directory of the avc ftp site. Please note that APC-1480a in the Incoming directory should replace the APC-1480 in that directory which failed during upload. Please copy APC-1480a in the Incoming directory to the 9811_Tor directory as APC-1480 Again, I apoogise for my lateness, and attach the documents here to expedite their delivery. Best Regards, Douglas Clowes

1 0

Torino meeting: connectors and electrical plugs
by Tosco Federico 13 Nov '98

13 Nov '98

In addition to the information I sent you and in answer to some requests I have received, I give you some information about connectors and electrical plugs. Each seat in the auditorium and in sala Manzoni will be equipped with: * a 10Base-T (RJ45) connector, which can be plugged into the PC for connection to the LAN available for the meeting. * an electrical plug (220 Volt). Please note that the Italian bipolar electrical plugs are equal to the Swiss ones that you normally use in Geneva. The tripolar ones (including the earth connection) are different, because the three poles are aligned, while in Switzerland the central one is not aligned with the other ones. Regards Federico Tosco

1 0

Re: Delayed request for APC numbers
by Sakae OKUBO 13 Nov '98

13 Nov '98

Dear Mr. Douglas Clowes, > I apologize for the lateness of my request, but I would like to present > some documents at the Torino meeting next week. The material I would like > to present relates to the Back End Services portion of the Inter-domain and > Inter-gatekeeper material in Annex G. I believe that this material relates > to your Q.13/16. > > I have two formal documents which I would like to submit: > > - Back-End Service Transaction Protocol (Protocol Description) > - Back-End Service Transaction Protocol (Technical Rationale) On an exceptional basis, APC-1480 and 1481 have been allocated to your contributions. Please upload them as soon as possible. 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 Editor H.323 Annex E: Call Signalling over UDP 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 Q15/16 Letter from Q.15 / SG 16 to Q.11 through Q.14 / SG 16 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 1480 OzEmail Interline Back-End Service Transaction Protocol (Protocol Description) 1481 OzEmail Interline Back-End Service Transaction Protocol (Technical Rationale) -----------------------------------------------------------------------

1 0