- sg16-avd - lists.packetizer.com

AW: Simulation condition for H.323 Annex I
by Baese Gero 23 Dec '00

23 Dec '00

Dear Mr. Li, experts, we heartily welcome your contribution to our co-operation for the tests. We provided an appropriate test scenario already(APC-1993), so there is no need for a complete new document. This scenario is well substantiated and intended as a framework for further completions. Would you please be so kind to incorporate your suggestions in the existing document? This would help all of us to reach a consensus soon. We wish a peaceful christmas time and a happy new year for everybody around the globe. Best regards Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Simulation condition for H.323 Annex I
by Adam Li 22 Dec '00

22 Dec '00

Dear experts of Q.2 and Mr. Gero, Enclosed is the simulation condition we drafted for H.323 Annex I. Hope both ULP and UXP groups can generate simulations results can be used to compare the two proposals by the next meeting. As requested by Mr. Skran in the last Rapporteor's meeting, we would like to start working on a joint contribution together with Mr. Gero and the UXP group on comparisons of the two proposals based on APC-2019. We can start on the comparison of compatibility, complexity and other aspects, and add the performance comparison in when the data are available. Have a good holiday, and happy new year. Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)

1 0

VIP Listing #323F
by Bob Nicson 21 Dec '00

21 Dec '00

***** This is an HTML Message ! *****

1 0

Re: Third party registration/group registration
by Agboh, Charles 21 Dec '00

21 Dec '00

-----Original Message----- From: Chris Purvis [mailto:chrisp@ISDN-COMMS.CO.UK] Sent: Tuesday, December 19, 2000 1:24 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, >> The examples about the >> secretary and her boss won't work with Chr*s because (i think), if the >> secretary and boss are both H.323 complaint then they should be able to >> register themselves (I disagree with this). >This is only half the story. I'm also saying that I don't believe third-party >registration is necessary to achieve this, and that the relevant intelligence >should reside in the gatekeeper. >> In the case of the IWF >> (s*p-h323) this is not true. >No. In the case of the IWF I will send my setup message to the same entity that >has been doing the registering. I'm not saying this won't work. I'm merely >saying I don't understand why you consider this to be "third-party". Sorry Chris, you are right. I was talking about H.323 complaince of all the parties considering the scenario with the IWF. >> The real question for now is, what value will 3rd-party registration bring >> to an H.323 network. Once we have determined this, then we can proceed to >> agree on a good definition. >True. My suggested way forward: >Focus on what you're trying to achieve, then work out whether anything needs to >be added to the standards to achieve it. THEN start thinking about how to >achieve it, and what terms should be used to describe it! Yes, I agree. >Regards, >Chris Regards, Charles -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.248 Annex M Debate
by Tom-PT Taylor 20 Dec '00

20 Dec '00

A private debate has been taking place (between David Cromwell and Markus Pauls) over whether H.248 Annex M should be restored to a structure which optimizes the operation with the IN. Should that debate be broadened to this list or to the Megaco list? Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 Cell +1 613 290 0844 taylor(a)nortelnetworks.com

2 1

regarding ifIndex used in H.341
by Shshank_Sharma 20 Dec '00

20 Dec '00

Hi All, I am a new entrant to this mailing list and appreciate the time and effort you spend on it. I am in a slight quandary. I am writing three agents (with separate functionalities) for a network element that is an H323 gatekeeper. Two of these agents are based on the mandatory MIBs for an H.323 Gatekeeper (the RAS-MIB and the H323-GATEKEEPER-MIB, B.2 and B.4 respectively,as given in Annex B of the ITU-T H.341 Recommendation *Multimedia Management Information Base*) These MIBs use ifIndex from Interfaces MIB (RFC 1573, 2233). > I have queried regarding the problem with Mr.Keith McCloghrie of Cisco > Systems who is one of the authors of the RFCs on this (RFC1573,2233) and > he appears to be of the opinion that the definitions are probably broken. I'll describe the problem below. The description of the following notifications seems to be broken.They use ifIndex as an object of the notification, while it is specified in the RFCs mentioned above that the semantics of an ifIndex value is to identify a network interface, not a network element such as the Gatekeeper, as the Description of these notifications shows. I wish to ascertain the purpose of using ifIndex in these MIBs and what it stands for from among the following ** Multiple Gatekeepers within managed system ? ** Multiple physical network interfaces of s single gatekeeper ? Further, RFC 2578 specifies that a single value of a MIB "Counter has (in general) no information content" (see section 7.1.6). Therefore, it is contrary to the SMI to specifythat "All MIB counters have gone to zero". Please clarify regarding the same. Any and all comments will be appreciated. Best Regards, --Shshank The notifications are given as follows: #1 **************************************************************************** ***** Name: h323GatekeeperStart Type: NOTIFICATION-TYPE OID: 0.0.8.341.1.1.6.6.0.1 Full path: oid_ccitt(0).oid_recommendation(0).oid_h(8).oid_h341(341).mmRoot(1).mmH323Ro ot(1).h323Gatekeeper(6).oid_ 0_0_8_341_1_1_6_6(6).h323GatekeeperNotifications(0).h323GatekeeperStart(1) Module: H323-GATEKEEPER-MIB Parent: h323GatekeeperNotifications Next sibling: h323GatekeeperGoingDown Status: current Objects: 1: ifIndex Description: Signifies that the gatekeeper has started. All MIB counters have gone to zero. **************************************************************************** ***** #2 **************************************************************************** ***** Name: h323GatekeeperGoingDown Type: NOTIFICATION-TYPE OID: 0.0.8.341.1.1.6.6.0.2 Full path: oid_ccitt(0).oid_recommendation(0).oid_h(8).oid_h341(341).mmRoot(1).mmH323Ro ot(1).h323Gatekeeper(6).oid_ 0_0_8_341_1_1_6_6(6).h323GatekeeperNotifications(0).h323GatekeeperGoingDown( 2) Module: H323-GATEKEEPER-MIB Parent: h323GatekeeperNotifications Prev sibling: h323GatekeeperStart Next sibling: h323GatekeeperError Status: current Objects: 1: ifIndex Description: Signifies that the gatekeeper is about to go down **************************************************************************** ***** #3 **************************************************************************** ***** Name: h323GatekeeperError Type: NOTIFICATION-TYPE OID: 0.0.8.341.1.1.6.6.0.3 Full path: oid_ccitt(0).oid_recommendation(0).oid_h(8).oid_h341(341).mmRoot(1).mmH323Ro ot(1).h323Gatekeeper(6).oid_ 0_0_8_341_1_1_6_6(6).h323GatekeeperNotifications(0).h323GatekeeperError(3) Module: H323-GATEKEEPER-MIB Parent: h323GatekeeperNotifications Prev sibling: h323GatekeeperGoingDown Status: current Objects: 1: ifIndex 2: h323GatekeeperStatisticsLastErrorEventTime 3: h323GatekeeperStatisticsLastErrorSeverity 4: h323GatekeeperStatisticsLastErrorProbableCause Description: Signifies that an error has occurred in the Gatekeeper. **************************************************************************** ***** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Get Your listing #404C
by Harry Stewart 19 Dec '00

19 Dec '00

***** This is an HTML Message ! *****

1 0

Most recent document showing corrections to H.323 and H.225.0
by Paul E. Jones 19 Dec '00

19 Dec '00

Folks, I was asked to clarify the text in section 1.5 so relating to the logical channel numbers of bi-directional channels. I just changed this a few minutes ago.. so it is new :-) Please look at that and all other sections (if you have not yet reviewed the document), as I would like to see all of these corrections inserted into H.323v4 and H.225.0v4 prior to publication, if at all possible. If you have any concerns or objections, please let me know. Thanks, Paul

1 0

Re: Third party registration/group registration
by Agboh, Charles 19 Dec '00

19 Dec '00

Hi Roy; What ever you do, don't mention S*P for now. We are trying to keep the third party registration feature in the H.323 realm. The examples about the secretary and her boss won't work with Chr*s because (i think), if the secretary and boss are both H.323 complaint then they should be able to register themselves (I disagree with this). In the case of the IWF (s*p-h323) this is not true. The real question for now is, what value will 3rd-party registration bring to an H.323 network. Once we have determined this, then we can proceed to agree on a good definition. Then, we can move onto how to define the procedure in H.323 (IE). Based on the definition, the third-party may or may not actively remain in the call (he may receive call progress information,...). H.323 proxy is an example of an H.323 entity that may not be fully complaint but still remains actively in the call. I have given some examples about the value of third-party registration but I am told that the value of those examples can be achieved with static GK configuration. I think it may be useful in some roaming scenarios (H.323 annex H). There is also the example of the fully complaint decomposed endpoint (for administative reasons). Best Regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Friday, December 15, 2000 6:12 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Hi, Chris and Charles: I guess that the third party registration will be helpful in a situation where the first does not want to do this job and may want to delegate this to the third party (e.g., secretary). Another situation can be that an IWF is registering many entities on behalf of many endpoints and the IWF does not want to be a party anymore once the registration is done. Let us define the requirements of the third party registration as follows: 1. The third party wants to register the first party. 2. The third party shall not be any party once the registration is done. That is, any information related to the first party needs to be obtained from other sources once the registration is done by the third party. Based on the above two criteria, let us see what needs to be done in H.323 to perform the third party registration. Hope this helps. Best regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 15, 2000 4:38 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, Ref your "some value": I would bring this down to configuration of the gatekeeper. You could have/configure/write!? a gatekeeper which has "default registrations" - calls for known people go by default to an answering machine unless that individual is actually registered. What I don't understand is how "third-party registration" helps - you're missing out too many steps in your explanation! Regards, Chris "Agboh, Charles" wrote: > > That is a good questions. I would say this; > > 3rd party registration is when; The target endpoint (called party ) may not > be the Registering Entity (IWF/BE) based on the binding between alias and > transport address; AND the entity receving the RRQ is aware that this is a > 3rd-party RRQ ( a registers b). > > This needs to be clearly defined but before that we must be sure there is > value in defining 3rd party registration (like third party call control: > GK-initiated call control (re-routing...)) > > some value: > > - In this case I do not have to hunt for a "line" at the GK (so at the > GK, I would know that a call was for a registered EP b (registered by > registering entity a) and send the call to the transport address which b's > alias is binded to (called party is b's alias address); which may be a's > transport address depending on the time). With the alternateEndpoint > structure, I would reach b only after hunting. > > Best regards, > charles > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Tuesday, December 12, 2000 9:52 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > I guess that it is a good observation by Bob. It can be thought a "kind" of > third party activities. However, a BE becomes a "party" in this process > because people have now have a place to go to have the information. And that > place is the BEs themselves. > > So the basic question remains: What is the basic definition of the "third" > party registration in H.323? > > Thanks Bob for his important observation. > > Best regards, > Radhika > > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Tuesday, December 12, 2000 3:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > I might interject that H.225.0 Annex G can be thought of as a form of Third > Party registration. This protocol allows a Border Element (or Gatekeeper) > to registers its endpoints with other Border Elements (or Gatekeepers). > > I do not know is this adds to the discussion, or not. > > Bob > > -------------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > 5500 Broken Sound Blvd, Boca Raton, Fl 33487 > Tel: +1 561 923-1756 Fax: +1 561 923-1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ----------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 18 Dec '00

18 Dec '00

Hi, Charles: Yes, if the objectives are satisfied somehow, we do not need to do any especial standard works just for the "Third Party." We will see as you go down the road. I have just explained the things how we should analyze the problem. Best regards, Radhika -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@gts.com] Sent: Monday, December 18, 2000 11:28 AM To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: Third party registration/group registration Hi Roy; What ever you do, don't mention S*P for now. We are trying to keep the third party registration feature in the H.323 realm. The examples about the secretary and her boss won't work with Chr*s because (i think), if the secretary and boss are both H.323 complaint then they should be able to register themselves (I disagree with this). In the case of the IWF (s*p-h323) this is not true. The real question for now is, what value will 3rd-party registration bring to an H.323 network. Once we have determined this, then we can proceed to agree on a good definition. Then, we can move onto how to define the procedure in H.323 (IE). Based on the definition, the third-party may or may not actively remain in the call (he may receive call progress information,...). H.323 proxy is an example of an H.323 entity that may not be fully complaint but still remains actively in the call. I have given some examples about the value of third-party registration but I am told that the value of those examples can be achieved with static GK configuration. I think it may be useful in some roaming scenarios (H.323 annex H). There is also the example of the fully complaint decomposed endpoint (for administative reasons). Best Regards, charles -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Friday, December 15, 2000 6:12 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Hi, Chris and Charles: I guess that the third party registration will be helpful in a situation where the first does not want to do this job and may want to delegate this to the third party (e.g., secretary). Another situation can be that an IWF is registering many entities on behalf of many endpoints and the IWF does not want to be a party anymore once the registration is done. Let us define the requirements of the third party registration as follows: 1. The third party wants to register the first party. 2. The third party shall not be any party once the registration is done. That is, any information related to the first party needs to be obtained from other sources once the registration is done by the third party. Based on the above two criteria, let us see what needs to be done in H.323 to perform the third party registration. Hope this helps. Best regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, December 15, 2000 4:38 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, Ref your "some value": I would bring this down to configuration of the gatekeeper. You could have/configure/write!? a gatekeeper which has "default registrations" - calls for known people go by default to an answering machine unless that individual is actually registered. What I don't understand is how "third-party registration" helps - you're missing out too many steps in your explanation! Regards, Chris "Agboh, Charles" wrote: > > That is a good questions. I would say this; > > 3rd party registration is when; The target endpoint (called party ) may not > be the Registering Entity (IWF/BE) based on the binding between alias and > transport address; AND the entity receving the RRQ is aware that this is a > 3rd-party RRQ ( a registers b). > > This needs to be clearly defined but before that we must be sure there is > value in defining 3rd party registration (like third party call control: > GK-initiated call control (re-routing...)) > > some value: > > - In this case I do not have to hunt for a "line" at the GK (so at the > GK, I would know that a call was for a registered EP b (registered by > registering entity a) and send the call to the transport address which b's > alias is binded to (called party is b's alias address); which may be a's > transport address depending on the time). With the alternateEndpoint > structure, I would reach b only after hunting. > > Best regards, > charles > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Tuesday, December 12, 2000 9:52 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > I guess that it is a good observation by Bob. It can be thought a "kind" of > third party activities. However, a BE becomes a "party" in this process > because people have now have a place to go to have the information. And that > place is the BEs themselves. > > So the basic question remains: What is the basic definition of the "third" > party registration in H.323? > > Thanks Bob for his important observation. > > Best regards, > Radhika > > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Tuesday, December 12, 2000 3:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > I might interject that H.225.0 Annex G can be thought of as a form of Third > Party registration. This protocol allows a Border Element (or Gatekeeper) > to registers its endpoints with other Border Elements (or Gatekeepers). > > I do not know is this adds to the discussion, or not. > > Bob > > -------------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > 5500 Broken Sound Blvd, Boca Raton, Fl 33487 > Tel: +1 561 923-1756 Fax: +1 561 923-1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ----------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0