- sg16-avd - lists.packetizer.com

Usage of CallID in H.323v2 for rerouted (diverted, transferred,.. .) calls
by Klaghofer Karl PN VS LP3 16 Nov '98

16 Nov '98

H.225.0v2 CallID identifies the call with which the message is associated (all RAS and Call Signalling messages related to the same call). Is it allowed that the CallID value for a rerouted call (second Setup) may be the same as the CallID value used in the first call Setup message ? According to H.323v2 clause 7.5 second last sentence it is even recommended (e.g. reference to Fig. 19/H.323 where all messages shown in the figure shall use the same CallID) ? However, I would like this to be confirmed, since somebody might interpret this as contradicting with the definition of the call identifier. If we can confirm this, then I propose that such a usage of the CallID is also possible for H.450.x related call redirections (e.g. Call Diversion, Call Transfer). This would allow the calls (e.g. first call setup and diverted call) to be associated for applications. As an alternative, we might add a new multilevel CallID (e.g. to H.225.0 v3) that consists of an identifier that indicates the "overal call" and a second identifier that indicates the call leg. Thanks, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

APC-1456.
by Yair Miranda 15 Nov '98

15 Nov '98

Dear Mr. Okubo, I have uploaded an updated version of APC-1456 to 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: APC No for Contribution to Q14/SG16
by Sakae OKUBO 14 Nov '98

14 Nov '98

Dear Mike Buckley, Your request is very late. Let me consult with the meeting how to handle your contribution (APC numbered document or TD or other way). In the meantime please upload your document at the /Incoming directory with an appropriate file name and announce your uploading on the reflector for the interest of the group members. 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 *********************************************************** At 23:26 +0900 98/11/13, Mike Buckley wrote: > Mr Okubo, > > We would like to submit a contribution to next weeks Q11, Q12, Q13, Q14 > meeting in Turin. I realise that the deadline for submissions is now past, >and I > apologise for the lateness. The contribution relates to the Media Gateway > Control Protocol and will probably contain a number of companies names > including Lucent Technologies. > > I would be very grateful if you could allocate an APC number. > > Many Thanks, > > Mike Buckley > Lucent Technologies > +44-145-877718 (T) > +44-145-877721 (F) > mikebuckley(a)lucent.com

1 0

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 14 Nov '98

14 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