- sg16-avd - lists.packetizer.com

Re: H.248 Annex M IPR
by Sebestyen Istvan ICN M SR 3 10 Jan '01

10 Jan '01

Tom, many thanks for this to Nortel. H.248 is generally a very important standard, so - in my view - for an easier breakthrough in the market it would be nice if at least all essential parts of H.248 could follow the same pattern. Is there somewhere a compilation on a working group level on a best effort basis (I mean not an internal patent search...) who has IPRs on what, and on what general conditions? Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M SR 3, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.icn.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/ ---------------------------------------------------------------------------- ---------------- > ---------- > From: Taylor, Tom-PT > [NORSE:B901:EXCH][SMTP:taylor@AMERICASM01.NT.COM] > Reply To: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Monday, January 08, 2001 8:55 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.248 Annex M IPR > > As I have indicated in the past, my company, Nortel Networks, claims IPR > in the draft H.248 Annex M (Advanced Audio Server packages). I am pleased > to say that management has decided to licence this IPR royalty-free. For > further information, contact Rick Witcher > mailto:jrwitcher@nortelnetworks.com. > > Tom Taylor > Multimedia Control and Applications Standards > Ph. +1 613 736 0961 > Cell +1 613 290 0844 > taylor(a)nortelnetworks.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ASN.1 query
by Pete Cordell 09 Jan '01

09 Jan '01

I'm not sure that I am looking at the latest version, but should: TBCD-STRING ::= IA5String (FROM ("0123456789#*abc")) contain 'd' in the restricted alphabet? Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 Annex M IPR
by Taylor, Tom-PT [NORSE:B901:EXCH] 08 Jan '01

08 Jan '01

As I have indicated in the past, my company, Nortel Networks, claims IPR in the draft H.248 Annex M (Advanced Audio Server packages). I am pleased to say that management has decided to licence this IPR royalty-free. For further information, contact Rick Witcher mailto:jrwitcher@nortelnetworks.com. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 Cell +1 613 290 0844 taylor(a)nortelnetworks.com

1 0

Re: OpenLogicalChannel parameter
by Audet, Francois [SC2:4K02:EXCH] 08 Jan '01

08 Jan '01

You are right. This looks like a mistake in Annex F/H.323. It should say "# of frames" in the diagram and in the text below. The current text conflicts with the rest of H.323 and H.225.0 and H.245. Paul, another one for the implementor's guide? -----Original Message----- From: stefan Jung [mailto:stefan.jung@dsp.se] Sent: Monday, January 08, 2001 1:16 AM To: H.323 Implementors Subject: OpenLogicalChannel parameter Hi All, I need help with the intepretation of a parameter in the Open Logical Channel structure. The problem I have is when i read the AnnexF specification. In the AnnexF chapter 10.1.1.1 there is a layout of the logical channel structure that shall be used by the SET device for the codecs G.711 and G.729. In the structure there is a parameter denoted "# samples". The definition is : For codecs G.711 A law 64 kbit/s, G.711 56 kbit/s u law 64 kbit/s, ulaw 56 kbit/s and G.729 Annex A this component contains the number of samples -1 per audio packet as defined in H.245. The problem with this definition is that it is not specified in that way in H.245. In H.245 it is stated that all saple based codecs are considered as frame based with a frame length of 1 ms. So how shall the "#samples " be interpreted ? If it is actually samples then the maximum value seems a bit small. The parameter is 8 bits which gives a maximum of 256 samples. This corresponds to 32 ms in G.711. A more reasonable interpretation would be to consider the parameter as "frames" instead. This would then give a more flexible range of the packet size and it would fit better with the definitions of H.245. Any input to clarify would be appreciated. Best regards /Stefan Jung

1 0

Re: CONNECT ACK in H.235
by Audet, Francois [SC2:4K02:EXCH] 08 Jan '01

08 Jan '01

I'd support that. Sounds like something for the implementor's guide. Thanks. > -----Original Message----- > From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] > Sent: Monday, January 08, 2001 8:32 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: AW: CONNECT ACK in H.235 > > > François, > > thanks for pointing this out. You are right: the mentioned > Connect Acknowledge message is indeed forbidden. > > I have no explanation why this contradiction remains there > since H.235v1. I can only assume, that this must be an > oversight since then that no one has noticed so far. It is > absolutely not the intention of H.235 to mandate forbidden messages. > > My proposal is to remove the contradiction here by deleting > the two words "CONNECT ACKNOWLEDGE". > > Any comments, objections? > > I would file an entry to the H.323 Implementors Guide. > > Kind Regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Phone: +49 89 722 55790 > | Martin Euchner Fax : +49 89 722 46841 > | Siemens AG > | ICN M NT 5 > mailto:Martin.Euchner@icn.siemens.de > <mailto:Martin.Euchner@icn.siemens.de> > | > mailto:martin.euchner@ties.itu.int > <mailto:martin.euchner@ties.itu.int> > | Hofmannstr. 51 Intranet: > http://intranet.icn.siemens.de/marketing/network_technology/se curity/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] Gesendet am: Mittwoch, 3. Januar 2001 22:45 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: CONNECT ACK in H.235 Guys, H.235v2 section 7.1 talk about receiving a CONNECT ACKNOWLEDGE message with insufficient security capabilities. Problem is that the CONNECT ACK message is forbidden in H.225.0. Anybody knows what this is all about? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: CONNECT ACK in H.235
by Euchner Martin 08 Jan '01

08 Jan '01

François, thanks for pointing this out. You are right: the mentioned Connect Acknowledge message is indeed forbidden. I have no explanation why this contradiction remains there since H.235v1. I can only assume, that this must be an oversight since then that no one has noticed so far. It is absolutely not the intention of H.235 to mandate forbidden messages. My proposal is to remove the contradiction here by deleting the two words "CONNECT ACKNOWLEDGE". Any comments, objections? I would file an entry to the H.323 Implementors Guide. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] Gesendet am: Mittwoch, 3. Januar 2001 22:45 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: CONNECT ACK in H.235 Guys, H.235v2 section 7.1 talk about receiving a CONNECT ACKNOWLEDGE message with insufficient security capabilities. Problem is that the CONNECT ACK message is forbidden in H.225.0. Anybody knows what this is all about? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC numbers for H.248 Annex F corrections
by OKUBO Sakae 05 Jan '01

05 Jan '01

Dear Mr. Hellstrom, >Please issue two APC-numbers for next meeting of Q.3/16 (?) and remind me >when it is. The next meeting of WP2/16 Questions (D, F, G, 1-5) will be held during 5-9 March in Australia (Melbourne or another city). A Rapporteur in turn will act as document manager, Mr. Paul Jones <paulej(a)packetizer.com> for the March meeting. He will allocate AVD-numbers to your contributions (Audio, Video and Data, no more APC). This and other information on the organization of WP2/16 Questions will soon be posted at the reflector. Best regards, OKUBO Sakae *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** At 00:51 +0100 01/01/05, Gunnar Hellstrom wrote: >From: "Gunnar Hellstrom" <gunnar.hellstrom(a)omnitor.se> >To: "Sakae Okubo" <okubo(a)giti.or.jp> >Cc: "Glen Freundlich" <ggf(a)lucent.com> >Subject: APC numbers for H.248 Annex F corrections >Date: Fri, 5 Jan 2001 00:51:22 +0100 >X-Priority: 3 (Normal) >Importance: Normal > >Dear Sakae Okubo > >Please issue two APC-numbers for next meeting of Q.3/16 (?) and remind me >when it is. >-------------------------------------------------------------------------- > >Title: H.248 Annex F Text, Fax and Call discrimination packages corrections > >Source: Editor, G.Hellstr $BSN (B, LM Ericsson > >Purpose: Proposal > >Abstract: Some errors in the numbering of parameters have been discovered in >H.248 Annex F. This document proposes corrections for these errors in the >form of a corrcted document. > >--------------------------------------------------------------------------- > >Title: H.248 Implementor guide additions for H.248 Annex F. > >Source: Annex F Editor, G.Hellstr $BSN (B, LM Ericsson > >Purpose: Proposal > >Abstract: Some errors in the numbering of parameters have been discovered in >H.248 Annex F Fax, text and call discrimination. This document proposes >corrections for these errors in the form of additions to the H.248 >implementors guide. > >Best regards > >Gunnar Hellstr $BSN (B >**************************************** >Gunnar Hellstr $BSN (B >Ericsson Radio Systems AB >tel $B%) (B+46 708 204 288 >gunnar.hellstrom(a)era.ericsson.se >***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

CONNECT ACK in H.235
by Francois Audet 03 Jan '01

03 Jan '01

Guys, H.235v2 section 7.1 talk about receiving a CONNECT ACKNOWLEDGE message with insufficient security capabilities. Problem is that the CONNECT ACK message is forbidden in H.225.0. Anybody knows what this is all about? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

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

29 Dec '00

Dearm Mr. Li, experts, thank you very much for your response. For everybody not directly related to the simulations would it be very hard to understand what the test conditions are about using the new document only. The decisions for special values(e.g. bitrate) should be reproducable, therefore a complete scenario is an indispensable requirement. > The simulation condition we provided in the last email has > incorporated both the conditions used in our simulation presented in Portland > and the conditions you proposed in Geneva That is, the workload for you would be very small to incorporate your suggestions at the appropriate places in the test scenario document APC-1993. Please be so kind and then let's move on to the next step. Thank you for your co-operation. Best wishes 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

Correction needed to H.245 V7, ASN.1 syntax
by Paul, Manoj 28 Dec '00

28 Dec '00

There is a correction required in H.245 Version 7 spec. Closing brace for RefPictureSelection sequence is missing in the document. -Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

Re: Fast Connect & Bi Directional channels
by Sasha Ruditsky 17 Dec '00

17 Dec '00

Hi Bob First of all I disagree that the caller determine the logicalChannelNumber for the channels from callee to caller, H.323 in 8.1.7.1 states: ..... When accepting a proposed channel for transmission from called endpoint to calling endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a unique forwardLogicalChannelNumber into the OpenLogicalChannel structure ... ..... And the standard states nothing about forwardLogicalChannelNumber in the proposal for such channel. So the calling entity allocates forwardLCN for channels transmitted on which it will transmit. The caller that wants to associate the accepted OLC with proposed OLC may do this only using dataType parameter and BTW this is one of the reasons why this parameter should be never changed by called entity. ---------------------------------------------------------------------------- --------------------------------------------------------- BUT, From the other hand I do agree that making forward and reverse LCN equal will work. And to be honest this is probably the least ugly solution known till know. Unfortunately, it will require from the implementation of callee the sophisticated LCN allocation mechanism that allows allocation of LCNs while taking into account the fact that some of LCNs were preallocated for bi directional channels by the caller. Fortunately, as for now, there is just one such LCN possible! Sasha -----Original Message----- From: Bob Gilman [mailto:rrg@AVAYA.COM] Sent: Wednesday, December 13, 2000 7:43 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels Sasha- I have the following comments about your four proposals: 1. Do we really loose the reverse LCN with this option, or is it just the same as the forward LCN? With this latter view, we could then invoke H.245 later on the forward and/or the reverse channels. This should work because, at the time Fast Connect is used, there would be no other channel numbers assigned to interfere. I'd hate to lose the uniqueness of the channel numbers within the offered/accepted OLCs. Also, this is exactly the same as what we do now with unidirectional channels: the caller determines the channel numbers for both the forward (calller to callee) and the reverse (callee to caller) channels. I don't believe there is any restriction in H.245 that requires the forward channel numbers to be different from the reverse channel numbers; the asymmetry of the commands and responses makes the coding unique. 2. I think using the replacementFor field should be avoided because this can adversely affect SETs. 3. I agree. 4. It's tough to add a new field at this stage - especially since it would be in H.245! What do you think? -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 Sasha Ruditsky wrote: > > Hi Paul > > First of all I want to be completely certain about the value of the > forwardLogicalChannelNumber in the response to the bi-directional channel > proposal. > > If we agree that it should be the same value as in the corresponding field > from the proposal OLC then following solutions are possible (and no one is > perfect): > > 1 Leave everything as it is. (Loosing the ReverseLCN as I already > described). > 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN). > For me it is a little bit ugly, but excelent solution. > I am almost certain that it breaks nothing in nonSET H.323. > But it probably may cause problems to SET with multiple fast starts. > 3 I would really not want to do this through nonStansard fields. > 4 To add new field: > OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber. > The only problem with this is that we need to change the H.245 > syntax. > In addition this field is difficult to explain from the H.245 point > of view. > (I do not think we've had ever before a precedent of changing H.245 > as a result of > fast start needs) > > I really do not know which one I prefer. > > Sasha > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Wednesday, December 13, 2000 6:57 AM > To: Sasha Ruditsky > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Fast Connect & Bi Directional channels > > Sasha, > > Yes, I see your point now.. thanks for clarifying this issue for me. > > This makes life more interesting, doesn't it? > > So I suppose the question is one of whether we feel we need to provide this > information or whether we do not. To keep life simpler for the H.245 state > machine, I would guess that we should do something to allow the called > endpoint to return the LCN for the reverse channel. However, there doesn't > seem to be a real clean place to provide that information. We could always > do strange things, such as use nonStandard fields or use the > "replacementFor" field in the OLC.reverseLogicalChannelParameters structure. > > What's your preference? > > I would guess that the proponents of this text (who wanted it for Annex Dv2 > primarily) should have something to say regarding this. > > Paul > > ----- Original Message ----- > From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> > To: "Paul E. Jones" <paulej(a)packetizer.com> > Cc: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Tuesday, December 12, 2000 3:28 AM > Subject: RE: Fast Connect & Bi Directional channels > > > Hi Paul > > > > When we open T.120 or any other bi-directional channel through the H.245 > > then openLogicalChannelAck message carries 2 LCNs: > > 1st in the forwardLogicalChannelNumber field > > 2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber > field > > So when opening the real H.245 channel there is no problem. > > > > With fast start the problem exists because the openLogicalChannel message > > (the response for fast start case) has just one LCN field -- the > > forwardLogicalChannelNumber. > > > > It should be decided what should be the value of this field. > > Currently standard says nothing about this field specifically. > > The H.323 states in 8.1.7.1 : "When accepting a proposed bi-directional > > channel for transmission between the calling endpoint and the called > > endpoint, the called endpoint shall return the corresponding > > OpenLogicalChannel structure to the calling endpoint.". > > In the same section before there is note: "The called endpoint is only > > allowed to alter fields in a proposed OpenLogicalChannel structure as > > specified in this section". > > > > I believe that from the lawyer point of view the aforementioned means: > "the > > forwardLogicalChannelNumber" should not be changed. > > > > I do not know if this was exactly the intent, but if it was, it is OK with > > me, except the fact that we do not have the reverseLogicalChannelNumber > > field for such channel. > > In most cases it does work OK. The only case that may cause problem is > > inheritance of such channel by H.245. The reverse direction of the > > bi-directional H.245 channel opened in such way will not be able to be a > > subject of the H.245 commands and indications. I know no H.245 commands > and > > indications that is impossible to work without when working with fax > > channel. So I do not think that we have specific problem which may affect > > fax channels opened in such way. > > > > >From other hand the procedure is (a little bit, but) broken. So at least > > this should be understood and mentioned in the standard. > > > > -------------------------------------------------------------------------- > -- > > -------------------------- > > The possible alternative (of cause if we do agree that the standard is > > unclear in this point) is two put the reverseLogicalChannelNumber into the > > forwardLogicalChannelNumber field of the accepted bi-directional channel. > > This solves the problem, but requires the caller to implement more > > complicated mechanism to identify to the proposed OLC for the received > > accepted OLC. > > > > -------------------------------------------------------------------------- > -- > > -------------------------- > > But in any case I just want to be able to implement this so it should be > > agreed what is the proper value to be put in this field. > > > > Sasha > > > > > > > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Monday, December 11, 2000 11:10 PM > > To: Sasha Ruditsky; ITU-SG16(a)mailbag.cps.intel.com > > Cc: Orit Levin > > Subject: Re: Fast Connect & Bi Directional channels > > > > > > Sasha, > > > > This logic was borrowed from the way that we open bi-directional T.120 > > channels, I believe. Either endpoint may signal the opening of a T.120 > > channel, but only one side provides the LCN. Is this same logic not > > sufficient? > > > > Paul > > > > ----- Original Message ----- > > From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)PACKETIZER.COM> > > Sent: Monday, December 11, 2000 8:04 AM > > Subject: Fast Connect & Bi Directional channels > > > > > > > Hi > > > > > > It looks like there is yet another bug in the fast start procedure. > > > It is related to bi-directional channels establishment. > > > > > > Standard says that in each bi-directional channel proposal there should > be > > > unique forwardLogicalChannelNumber. > > > Standard says nothing about the value of this field in the accepted > > > bi-directional OLC. > > > > > > It is known that bi-directional channels need 2 logical channel numbers > > > (forward and reverse). > > > I see 2 options for the value of forwardLogicalChannelNumber field in > the > > > accepted bi-directional OLC: > > > > > > 1. It may be the same value as the forwardLogicalChannelNumber in the > > > corresponding proposal. > > > In this case we do not have the logical channel number for the reverse > > > direction. > > > This works OK till we are in fast start, but after H.245 connection > > > establishment > > > it will be impossible to perform H.245 actions on the reverse direction > of > > > the channel. > > > > > > 2. It may be the unique logical channel number that is provided by > calling > > > party and > > > identifies the channel -- the reverseLogicalChannelNumber. > > > The problem with this is that caller does not know to which proposal > this > > > channel belongs. > > > BTW The same problem exists with the unidirectional channels from callee > > to > > > caller and the solution > > > is just to find the corresponding proposal, using different channel > > > characteristics. > > > > > > I personally prefer the second option because it is more correct from > the > > > H.245 point of view. > > > But, In any case it should be decided which is the standard one . > > > > > > Sasha > > > > > > > > > > > > *********************************************** > > > Alexander(Sasha) Ruditsky > > > RADVision Ltd. > > > 24 Raul Wallenberg St. > > > Tel Aviv 69719 Israel > > > > > > Tel: +972-3-645-5220 > > > Fax: +972-3-644-2903 > > > Direct: +972-3-645-5273 > > > sasha(a)radvision.rad.co.il > > > *********************************************** > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

4 4

RE: Fast Connect & Bi Directional channels
by Sasha Ruditsky 17 Dec '00

17 Dec '00

Hi Paul Yes, I think that using the same number for the both LCNs of the bi-directional channel is the best solution for this problem. And I agree with the text that clarifies this. Sasha -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, December 16, 2000 9:48 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels Sasha, et al., Sorry for the last e-mail on this subject. I had not seen this one, yet. So, it appears that you agree that for bi-directional channels we can use the forward LCN as the value of the reverse LCN. I have attached the most recent documents containing corrections to H.323v4 and H.225.0v4, which includes a proposal for this item. Please review the text and give me comments. Best Regards, Paul ----- Original Message ----- From: "Sasha Ruditsky" <sasha(a)TLV.RADVISION.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Thursday, December 14, 2000 2:35 AM Subject: Re: Fast Connect & Bi Directional channels > Hi Bob > > First of all I disagree that the caller determine the logicalChannelNumber > for the channels from callee to caller, H.323 in 8.1.7.1 states: > ..... > When accepting a proposed channel for transmission from called endpoint to > calling endpoint, the called endpoint shall return the corresponding > OpenLogicalChannel structure to the calling endpoint, inserting a unique > forwardLogicalChannelNumber into the OpenLogicalChannel structure ... > ..... > > And the standard states nothing about forwardLogicalChannelNumber in the > proposal for such channel. > > So the calling entity allocates forwardLCN for channels transmitted on which > it will transmit. > The caller that wants to associate the accepted OLC with proposed OLC may do > this only using dataType parameter and BTW this is one of the reasons why > this parameter should be never changed by called entity. > -------------------------------------------------------------------------- -- > --------------------------------------------------------- > BUT, From the other hand I do agree that making forward and reverse LCN > equal will work. > And to be honest this is probably the least ugly solution known till know. > > Unfortunately, it will require from the implementation of callee the > sophisticated LCN allocation mechanism that allows allocation of LCNs while > taking into account the fact that some of LCNs were preallocated for bi > directional channels by the caller. > Fortunately, as for now, there is just one such LCN possible! > > Sasha > > > > -----Original Message----- > From: Bob Gilman [mailto:rrg@AVAYA.COM] > Sent: Wednesday, December 13, 2000 7:43 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Fast Connect & Bi Directional channels > > > Sasha- > I have the following comments about your four proposals: > 1. Do we really loose the reverse LCN with this option, or is it > just the same as the forward LCN? With this latter view, we > could then invoke H.245 later on the forward and/or the reverse > channels. This should work because, at the time Fast Connect is > used, there would be no other channel numbers assigned to interfere. > I'd hate to lose the uniqueness of the channel numbers within the > offered/accepted OLCs. Also, this is exactly the same as what we > do now with unidirectional channels: the caller determines the > channel numbers for both the forward (calller to callee) and the > reverse (callee to caller) channels. I don't believe there is any > restriction in H.245 that requires the forward channel numbers to > be different from the reverse channel numbers; the asymmetry of the > commands and responses makes the coding unique. > 2. I think using the replacementFor field should be avoided because > this can adversely affect SETs. > 3. I agree. > 4. It's tough to add a new field at this stage - especially since it > would be in H.245! > What do you think? > -Bob > ---------------------------------------------------- > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > Sasha Ruditsky wrote: > > > > Hi Paul > > > > First of all I want to be completely certain about the value of the > > forwardLogicalChannelNumber in the response to the bi-directional channel > > proposal. > > > > If we agree that it should be the same value as in the corresponding field > > from the proposal OLC then following solutions are possible (and no one is > > perfect): > > > > 1 Leave everything as it is. (Loosing the ReverseLCN as I already > > described). > > 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN). > > For me it is a little bit ugly, but excelent solution. > > I am almost certain that it breaks nothing in nonSET H.323. > > But it probably may cause problems to SET with multiple fast > starts. > > 3 I would really not want to do this through nonStansard fields. > > 4 To add new field: > > OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber. > > The only problem with this is that we need to change the H.245 > > syntax. > > In addition this field is difficult to explain from the H.245 > point > > of view. > > (I do not think we've had ever before a precedent of changing > H.245 > > as a result of > > fast start needs) > > > > I really do not know which one I prefer. > > > > Sasha > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Wednesday, December 13, 2000 6:57 AM > > To: Sasha Ruditsky > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Fast Connect & Bi Directional channels > > > > Sasha, > > > > Yes, I see your point now.. thanks for clarifying this issue for me. > > > > This makes life more interesting, doesn't it? > > > > So I suppose the question is one of whether we feel we need to provide > this > > information or whether we do not. To keep life simpler for the H.245 > state > > machine, I would guess that we should do something to allow the called > > endpoint to return the LCN for the reverse channel. However, there > doesn't > > seem to be a real clean place to provide that information. We could > always > > do strange things, such as use nonStandard fields or use the > > "replacementFor" field in the OLC.reverseLogicalChannelParameters > structure. > > > > What's your preference? > > > > I would guess that the proponents of this text (who wanted it for Annex > Dv2 > > primarily) should have something to say regarding this. > > > > Paul > > > > ----- Original Message ----- > > From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> > > To: "Paul E. Jones" <paulej(a)packetizer.com> > > Cc: <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Tuesday, December 12, 2000 3:28 AM > > Subject: RE: Fast Connect & Bi Directional channels > > > > > Hi Paul > > > > > > When we open T.120 or any other bi-directional channel through the H.245 > > > then openLogicalChannelAck message carries 2 LCNs: > > > 1st in the forwardLogicalChannelNumber field > > > 2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber > > field > > > So when opening the real H.245 channel there is no problem. > > > > > > With fast start the problem exists because the openLogicalChannel > message > > > (the response for fast start case) has just one LCN field -- the > > > forwardLogicalChannelNumber. > > > > > > It should be decided what should be the value of this field. > > > Currently standard says nothing about this field specifically. > > > The H.323 states in 8.1.7.1 : "When accepting a proposed bi-directional > > > channel for transmission between the calling endpoint and the called > > > endpoint, the called endpoint shall return the corresponding > > > OpenLogicalChannel structure to the calling endpoint.". > > > In the same section before there is note: "The called endpoint is only > > > allowed to alter fields in a proposed OpenLogicalChannel structure as > > > specified in this section". > > > > > > I believe that from the lawyer point of view the aforementioned means: > > "the > > > forwardLogicalChannelNumber" should not be changed. > > > > > > I do not know if this was exactly the intent, but if it was, it is OK > with > > > me, except the fact that we do not have the reverseLogicalChannelNumber > > > field for such channel. > > > In most cases it does work OK. The only case that may cause problem is > > > inheritance of such channel by H.245. The reverse direction of the > > > bi-directional H.245 channel opened in such way will not be able to be a > > > subject of the H.245 commands and indications. I know no H.245 commands > > and > > > indications that is impossible to work without when working with fax > > > channel. So I do not think that we have specific problem which may > affect > > > fax channels opened in such way. > > > > > > >From other hand the procedure is (a little bit, but) broken. So at > least > > > this should be understood and mentioned in the standard. > > > > > > > -------------------------------------------------------------------------- > > -- > > > -------------------------- > > > The possible alternative (of cause if we do agree that the standard is > > > unclear in this point) is two put the reverseLogicalChannelNumber into > the > > > forwardLogicalChannelNumber field of the accepted bi-directional > channel. > > > This solves the problem, but requires the caller to implement more > > > complicated mechanism to identify to the proposed OLC for the received > > > accepted OLC. > > > > > > > -------------------------------------------------------------------------- > > -- > > > -------------------------- > > > But in any case I just want to be able to implement this so it should be > > > agreed what is the proper value to be put in this field. > > > > > > Sasha > > > > > > > > > > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Monday, December 11, 2000 11:10 PM > > > To: Sasha Ruditsky; ITU-SG16(a)mailbag.cps.intel.com > > > Cc: Orit Levin > > > Subject: Re: Fast Connect & Bi Directional channels > > > > > > > > > Sasha, > > > > > > This logic was borrowed from the way that we open bi-directional T.120 > > > channels, I believe. Either endpoint may signal the opening of a T.120 > > > channel, but only one side provides the LCN. Is this same logic not > > > sufficient? > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> > > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)PACKETIZER.COM> > > > Sent: Monday, December 11, 2000 8:04 AM > > > Subject: Fast Connect & Bi Directional channels > > > > > > > > > > Hi > > > > > > > > It looks like there is yet another bug in the fast start procedure. > > > > It is related to bi-directional channels establishment. > > > > > > > > Standard says that in each bi-directional channel proposal there > should > > be > > > > unique forwardLogicalChannelNumber. > > > > Standard says nothing about the value of this field in the accepted > > > > bi-directional OLC. > > > > > > > > It is known that bi-directional channels need 2 logical channel > numbers > > > > (forward and reverse). > > > > I see 2 options for the value of forwardLogicalChannelNumber field in > > the > > > > accepted bi-directional OLC: > > > > > > > > 1. It may be the same value as the forwardLogicalChannelNumber in the > > > > corresponding proposal. > > > > In this case we do not have the logical channel number for the reverse > > > > direction. > > > > This works OK till we are in fast start, but after H.245 connection > > > > establishment > > > > it will be impossible to perform H.245 actions on the reverse > direction > > of > > > > the channel. > > > > > > > > 2. It may be the unique logical channel number that is provided by > > calling > > > > party and > > > > identifies the channel -- the reverseLogicalChannelNumber. > > > > The problem with this is that caller does not know to which proposal > > this > > > > channel belongs. > > > > BTW The same problem exists with the unidirectional channels from > callee > > > to > > > > caller and the solution > > > > is just to find the corresponding proposal, using different channel > > > > characteristics. > > > > > > > > I personally prefer the second option because it is more correct from > > the > > > > H.245 point of view. > > > > But, In any case it should be decided which is the standard one . > > > > > > > > Sasha > > > > > > > > > > > > > > > > *********************************************** > > > > Alexander(Sasha) Ruditsky > > > > RADVision Ltd. > > > > 24 Raul Wallenberg St. > > > > Tel Aviv 69719 Israel > > > > > > > > Tel: +972-3-645-5220 > > > > Fax: +972-3-644-2903 > > > > Direct: +972-3-645-5273 > > > > sasha(a)radvision.rad.co.il > > > > *********************************************** > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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

Draft IETF49 Megaco Minutes
by Tom-PT Taylor 15 Dec '00

15 Dec '00

The Megaco Working Group met on Wednesday morning, December 13. Tom Taylor [taylor(a)nortelnetworks.com] chaired. 1. Agenda Bashing The proposed agenda was as sent to the list (6/12/2000) with two additions: a brief presentation of work on Bearer Independent Call Control (BICC) and the proposed H.248 packages resulting from it, and presentation of draft-ietf-megaco-fmtdeterm-00.txt. The agenda as proposed was accepted. 2. ITU-T Study Group 16 Status Report ===================================== Tom Taylor provided an update on the status of work in Study Group 16. He reported that the ITU-T has introduced a new alternative decision procedure -- like Last Call -- if all issues not resolved, fall back on existing procedure. Scott Bradner added that the purpose in part was to make it easier to synchronize ITU-T and IETF decision processes. At the Study Group 16 meeting of 13-17 November the following items were decided under the old procedures: Annex F: Call discrimination, FAX, text telephony Annex G: User interface elements Annex H: SCTP transport Annex I: ATM transport Annex J: Dynamic tone generation Annex K: Announcements In addition, the meeting approved the first issue of the H.248v1 Implementor's Guide. Question 14/16 is now renamed Question 3/16 for the new Study Period. Q. 3/16 now has in hand the following additional official work items relating to H.248. There is no date set yet for completion of these items, but the two Annexes have been determined. -- H.248v2 -- Annex L: Error codes and ServiceChange reasons -- Annex M: Advanced audio server The following additional work items have been accepted, but are in an early state of maturity: -- Annex N: load control package (APC-2000) -- Annex O: data transport on analogue lines -- SDL appendix (informative). The contributors are looking for more help. -- H.324 package. Finally, the following H.248v2 items accepted, either at the Portland Rapporteur's meeting in August or at the November meeting: -- ServiceChange to indicate change of capabilities (APC-1911) -- Finer discrimination in audits (APC-1913) -- signal on ROOT. The APC numbers refer to document numbers on the informal SG 16 FTP site (ftp://standards.pictel.com/avc-site /<meeting place and date>) Tom noted that ITU-T versions are more like protocol extensions than protocol modifications. Successive versions are intended to be backwards compatible. Tom asked a process question: do we republish decided material as Informational or Standards Track? If the latter, presumably IETF comments go into the ITU-T Implementor's Guide. Flemming Andreasen [fandreas(a)cisco.com] identified the matter of how the IETF coordinates with the ITU-T in the development of H.248v2 as a major issue. This point should be considered in the rechartering discussion. Scott Bradner advised that no clear resolution of this point had been reached in discussions with Study Group 16 management. Further process discussion elicited the view that decided items of interest to the IETF should be taken through the complete IETF process and targeted for Standards Track RFCs. The list should decide which items should go this route. Scott Bradner instructed the Chair to get explicit permission from the ITU-T TSB before republishing the decided material, since it is not clear whether our agreement on H.248 extends beyond the initial protocol document. 3. Completion Of Charter Items ============================== (a) Megaco MIB ---------- Matt Holdrege [matt(a)IPVERSE.COM] provided a status report on the development of the Megaco MIB. He emphasized that the main purpose of the present draft was to get objects on the table for discussion. He estimated at least two recycles before the draft is in reasonable shape. He presented a long list of detailed issues to be worked through. [Presentation will be attached to published minutes]. There was no discussion at the meeting. (b) NAS Package ----------- Tom Taylor briefly summarized the status of the NAS packages. [Presentation to be attached to final minutes.] He pointed out that complementary work on indication of TDM bearer capability remained to be done. In his opinion this would be an SDP extension in the spirit of the ATM SDP extension. The hum in favour of moving this work forward was practically imperceptible: it is left to the list to decide. The Chair will be soliciting comment from the list on whether this should be a Standards Track item. 4. Well-Aged Package Drafts ======================== Michael Brown [C.Michael.Brown(a)nortelnetworks.com] presented all drafts under this heading, as co-author. (The presentation was actually interrupted but is documented here as if it had proceeded according to original plan.) (a) draft-boyle-megaco-tonepkgs-01.txt ---------------------------------- This document provides a number of specialized tone packages. [Presentation will be attached to minutes.] Michael noted that Study Group 11 (the BICC group) had asked for an optional directionality parameter for tones and announcements. Its use is to direct signals inwards to the context; it optimizes an operation which would otherwise require individual modification of all of the other terminations in the context or treatment of an announcement or tone source as a termination in its own right. The authors of draft-boyle-megaco-tonepkgs-01.txt propose to recycle the draft to include this parameter. Brian Rosen [Brian.Rosen(a)MARCONI.COM] expressed his view that the use of a directionality parameter for signals should be approved on the list. Glen Freundlich [ggf(a)avaya.com] noted that Study Group 16 added such a parameter to the new Annex K announcement package. The meeting agreed that the directionality parameter discussion is required, but otherwise the draft is ready for list Last Call. (b) draft-boyle-megaco-alerting-00.txt ---------------------------------- This package provides capabilities related to CLASS signalling. There is an overlap in scope with the proposed Annex O, but the latter has a finer level of detail which in Michael's opinion may result in timing difficulties. Brian Rosen asked if there had been coordination of approach between this work and automatic number identification (ANI/DNIS). Michael responded that the problems were similar, but not the same. The meeting agreed that before this draft moves forward there should be a discussion and resolution on the list of the respective content of this draft and the SG 16 Annex O proposal. Action: Chair to arrange for publication of current draft of Annex O as an I-D to aid the discussion. (c) draft-cornel-megaco-enhancedd-00.txt ------------------------------------ This draft defines an enhanced DTMF digit collection capability, designed particularly for mid-call digit collection. The package includes a modified digit map completion event. Scott Bradner noted with respect to this and previous items that non-response is not enough to justify standardization. The Chair must solicit discussion if necessary before deciding to move forward. (d) draft-scoggins-megaco-pktnetpkg-00.txt -------------------------------------- This package proposal is withdrawn in favour of packages included in the Q.1950 (BICC) work. 5. ITU-T Study Group 11 BICC Status ================================ Greg Ratta [gratta(a)lucent.com] SG 11 Vice Chairman in the area of IP-related signalling work, provided an introduction to Bearer Independent Call Control work dealing with IP networks. [Presentation charts will be attached to official minutes.] The presentation showed the basic architecture and listed two sets of packages: those picked up directly from H.248, and those developed by the BICC group specifically to suit their needs. The key architectural points are that call signalling is based on ISUP, with modifications to support an abstract interface to the media bearers. The protocol interface between the call server and lower-layer functions features a strict separation between bearer-related information and media-related information. Brian Rosen commented that he had read the BICC documents quickly and had come away with the sense that they violated the spirit of the H.248 protocol. He thought that SG 11 might need more H.248 expertise. He looked for a way to share our knowledge, with the intent of preserving a single protocol. Greg responded by recalling to Brian that Frame Relay, as an example, eventually saw application far beyond its original conception. He was open to the use of channels for the exchange of information between the two groups. The time for Megaco to get involved is definitely now, given that the documents have been determined and a final editing meeting has been scheduled for the latter half of February. Michael Ramalho [mramalho(a)cisco.com] seconded Brian's thoughts about the pooling of knowledge. However, he wondered why a project which seemed to be aimed at reproducing SS7 in the IP network should aim beyond that by emphasizing the separation between call control and bearer control. Greg responded that the main aim is to allow traditional networks to operate over new transport. The impetus for the call control/bearer control separation comes from the mobile area. Michael Brown noted that he had been somewhat involved in Study Group 11's work on BICC. The architecture forces transport of information differently from how H.248 does it. He raised the possibility that an alternative architecture would allow H.248 to operate as usual. He advised those present that, besides draft Q.1950, they should look at draft Q.1990 and the BICC requirements and architecture documents. Q.1950 is the document which Study Group 11 has just determined, and which will be the subject of the February editing meeting. Ian Rytina [ian.rytina(a)ericsson.com.au] warned that Megaco should not come barging into the midst of the BICC work shouting "All wrong!" without reflection. Study Group 16 people have been involved in BICC almost from the beginning. 6. ISDN ==== Bouwen Jan [jan.bouwen(a)alcatel.be] presented draft-bouwen-megaco-isdn-bcp-00.txt, draft-bouwen-megaco-isdn-data-00.txt, and draft-bouwen-megaco-isdn-pack-00.txt. [Presentation to be attached to official minutes.] The content has not changed significantly from the original draft, but it was broken into these three documents to make it easier to understand. Brian Rosen, commenting on the -isdn-pack draft, suggested that we need group consensus on the use of signals vs. the use of properties for management-type functions. We should decide one way or the other and enforce the chosen style in package definitions. Action is on the Chair to initiate list discussion. Related items in Study Group 16 are the proposed signal on ROOT for heartbeat messages, and proposed audio segment management operations in draft Annex M (Advanced Audio Server). Brian saw the BCP as a necessary document. However, naming patterns should go into profiles. He also wondered whether the modem descriptor should be used for D-channel data. The basic feeling was that the drafts other than the BCP document should move forward on Standards Track, but only after there had been more list discussion. The Chair undertook to focus discussion on the ISDN drafts in the coming week. Peter Blatherwick [blather(a)nortelnetworks.com] wondered whether the BCP document should actually be a profile. 7. CAS Design Team Report ====================== Michael Brown reported. draft-manyfolks-megaco-caspackage is on its way. The interest in channel-associated signalling (CAS) is large; the design team grew through word of mouth after it had been set up. The team sees the need for the following packages: - Basic CAS - Robbed bit signalling (wink/seizure) - MF generation and detection - Operator services The draft will be published shortly. List comment is encouraged. 8. Other Proposals =============== (a) draft-rosen-megaco-namepatterns-00.txt -------------------------------------- Brian Rosen presented. The mechanism is intended to help control the volume of information retrieved on audits. The intent is that the MGC retrieve this one property on ROOT, then walk through the patterns to retrieve information on groups of terminations. Tom Taylor noted that the mechanism allowed more precise designation than the one in the proposed NASROOT package. There is a need to reconcile the latter with Brian's proposals. Aside from the basic mechanism, a list debate is needed on whether ROOT packages should be defined in the manner of NASROOT to associate naming patterns with termination classes. This relates to the old problem of finding out about the MG's capabilities for ephemerals before any of the latter have been created. Michael Brown noted that the naming pattern in the MG may be purely physical (e.g. shelf/slot), and may not relate to the type of card (hence the termination class) provisioned there. (b) draft-cutler-megaco-recvpkg-01.txt ---------------------------------- Wayne Cutler [wayne.cutler(a)marconi.com] presented. The general intent is to allow the MGC to store state against individual terminations on MGs to allow a cleaner recovery from call failures. Flemming Andreasen termed the proposal bizarre at first sight. He asked whether the data to be stored included call state. Wayne indicated not, but that the data would be call-related. Flemming asked what would happen if multiple MGCs were involved. Wayne asked for clarification of whether Flemming meant multiple MGCs acting as a single logical MGC. Flemming complained of lack of generality. Brian Rosen stepped in to point out that the proposal is general with respect to content. Obviously a length limit would be needed. Scott Bradner noted that the author is simply asking for a cookie mechanism. The only concern is that it is defined too specifically. Clearly a matter for further discussion on the list. (c) draft-levy-megaco-mgdiscovery-01.txt ------------------------------------ Thomas LEVY [thomas.levy(a)ms.alcatel.fr] presented. The draft is intended to provide further information from the MG in support of load balancing. He reviewed the available alternatives and came up with a specific recommendation. Brian Rosen suggested that this work had the same time frame as SDPng, and thus the latter is the preferred route to a solution. Thomas responded that the expected incompatibility between SDP and SDPng made it desirable to find a solution independent of either. Scott Bradner suggested that we check out other resource capability work being done in the IETF. (d) draft-ietf-megaco-fmtdeterm-00.txt ---------------------------------- The Chair overlooked this item as the meeting was running out of time. It will be taken to the list for Last Call (Informational). 9. Interoperability ================ Brian Rosen reported on the results of the August interoperability event and gave some information on the next one. 10. Rechartering Discussion ======================= Scott Bradner led off discussion of the future of the Working Group by saying that WGs normally have a finite life. Working Groups are justified when they need meeting time to discuss open issues. He had not seen much evidence of such discussion at this meeting -- only a series of presentations. Brian Rosen spoke of a need to continue our work on packages. The lack of controversy at the present meeting was because the packages presented were well-baked. He also saw the need for an official working group to provide impedance to Study Group 16. The WG itself should not be working on a new version of Megaco -- only on packages. Matt Holdrege picked up the argument that Megaco is needed to provide legitimacy because the work it is involved in reaches beyond the IETF. Peter Blatherwick agreed that the group should continue its work on packages. He would also like to see more work on profiles, to provide rules for profile definition, how to do "inheritance", whether the MG can support multiple profiles at a time. This item was intentionally deferred earlier in the progress of WG, but there is serious risk of profiles getting out of control. Flemming Andreasen disagreed with this proposal. Scott Bradner called for a show of hands on continuing the Working Group. There were a fair number in favour of continuation and none in favour of going dormant. Scott instructed the Chair to take a draft charter to the list. The IESG might consider extension of the group's life, but the charter must contain concrete deliverables. Tom Taylor Ph. +1 613 736 0961 taylor(a)nortelnetworks.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: Fast Connect & Bi Directional channels
by Sasha Ruditsky 15 Dec '00

15 Dec '00

Hi Paul First of all I want to be completely certain about the value of the forwardLogicalChannelNumber in the response to the bi-directional channel proposal. If we agree that it should be the same value as in the corresponding field from the proposal OLC then following solutions are possible (and no one is perfect): 1 Leave everything as it is. (Loosing the ReverseLCN as I already described). 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN). For me it is a little bit ugly, but excelent solution. I am almost certain that it breaks nothing in nonSET H.323. But it probably may cause problems to SET with multiple fast starts. 3 I would really not want to do this through nonStansard fields. 4 To add new field: OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber. The only problem with this is that we need to change the H.245 syntax. In addition this field is difficult to explain from the H.245 point of view. (I do not think we've had ever before a precedent of changing H.245 as a result of fast start needs) I really do not know which one I prefer. Sasha -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, December 13, 2000 6:57 AM To: Sasha Ruditsky Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels Sasha, Yes, I see your point now.. thanks for clarifying this issue for me. This makes life more interesting, doesn't it? So I suppose the question is one of whether we feel we need to provide this information or whether we do not. To keep life simpler for the H.245 state machine, I would guess that we should do something to allow the called endpoint to return the LCN for the reverse channel. However, there doesn't seem to be a real clean place to provide that information. We could always do strange things, such as use nonStandard fields or use the "replacementFor" field in the OLC.reverseLogicalChannelParameters structure. What's your preference? I would guess that the proponents of this text (who wanted it for Annex Dv2 primarily) should have something to say regarding this. Paul ----- Original Message ----- From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> To: "Paul E. Jones" <paulej(a)packetizer.com> Cc: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, December 12, 2000 3:28 AM Subject: RE: Fast Connect & Bi Directional channels > Hi Paul > > When we open T.120 or any other bi-directional channel through the H.245 > then openLogicalChannelAck message carries 2 LCNs: > 1st in the forwardLogicalChannelNumber field > 2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber field > So when opening the real H.245 channel there is no problem. > > With fast start the problem exists because the openLogicalChannel message > (the response for fast start case) has just one LCN field -- the > forwardLogicalChannelNumber. > > It should be decided what should be the value of this field. > Currently standard says nothing about this field specifically. > The H.323 states in 8.1.7.1 : "When accepting a proposed bi-directional > channel for transmission between the calling endpoint and the called > endpoint, the called endpoint shall return the corresponding > OpenLogicalChannel structure to the calling endpoint.". > In the same section before there is note: "The called endpoint is only > allowed to alter fields in a proposed OpenLogicalChannel structure as > specified in this section". > > I believe that from the lawyer point of view the aforementioned means: "the > forwardLogicalChannelNumber" should not be changed. > > I do not know if this was exactly the intent, but if it was, it is OK with > me, except the fact that we do not have the reverseLogicalChannelNumber > field for such channel. > In most cases it does work OK. The only case that may cause problem is > inheritance of such channel by H.245. The reverse direction of the > bi-directional H.245 channel opened in such way will not be able to be a > subject of the H.245 commands and indications. I know no H.245 commands and > indications that is impossible to work without when working with fax > channel. So I do not think that we have specific problem which may affect > fax channels opened in such way. > > >From other hand the procedure is (a little bit, but) broken. So at least > this should be understood and mentioned in the standard. > > -------------------------------------------------------------------------- -- > -------------------------- > The possible alternative (of cause if we do agree that the standard is > unclear in this point) is two put the reverseLogicalChannelNumber into the > forwardLogicalChannelNumber field of the accepted bi-directional channel. > This solves the problem, but requires the caller to implement more > complicated mechanism to identify to the proposed OLC for the received > accepted OLC. > > -------------------------------------------------------------------------- -- > -------------------------- > But in any case I just want to be able to implement this so it should be > agreed what is the proper value to be put in this field. > > Sasha > > > > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Monday, December 11, 2000 11:10 PM > To: Sasha Ruditsky; ITU-SG16(a)mailbag.cps.intel.com > Cc: Orit Levin > Subject: Re: Fast Connect & Bi Directional channels > > > Sasha, > > This logic was borrowed from the way that we open bi-directional T.120 > channels, I believe. Either endpoint may signal the opening of a T.120 > channel, but only one side provides the LCN. Is this same logic not > sufficient? > > Paul > > ----- Original Message ----- > From: "Sasha Ruditsky" <sasha(a)tlv.radvision.com> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)PACKETIZER.COM> > Sent: Monday, December 11, 2000 8:04 AM > Subject: Fast Connect & Bi Directional channels > > > > Hi > > > > It looks like there is yet another bug in the fast start procedure. > > It is related to bi-directional channels establishment. > > > > Standard says that in each bi-directional channel proposal there should be > > unique forwardLogicalChannelNumber. > > Standard says nothing about the value of this field in the accepted > > bi-directional OLC. > > > > It is known that bi-directional channels need 2 logical channel numbers > > (forward and reverse). > > I see 2 options for the value of forwardLogicalChannelNumber field in the > > accepted bi-directional OLC: > > > > 1. It may be the same value as the forwardLogicalChannelNumber in the > > corresponding proposal. > > In this case we do not have the logical channel number for the reverse > > direction. > > This works OK till we are in fast start, but after H.245 connection > > establishment > > it will be impossible to perform H.245 actions on the reverse direction of > > the channel. > > > > 2. It may be the unique logical channel number that is provided by calling > > party and > > identifies the channel -- the reverseLogicalChannelNumber. > > The problem with this is that caller does not know to which proposal this > > channel belongs. > > BTW The same problem exists with the unidirectional channels from callee > to > > caller and the solution > > is just to find the corresponding proposal, using different channel > > characteristics. > > > > I personally prefer the second option because it is more correct from the > > H.245 point of view. > > But, In any case it should be decided which is the standard one . > > > > Sasha > > > > > > > > *********************************************** > > Alexander(Sasha) Ruditsky > > RADVision Ltd. > > 24 Raul Wallenberg St. > > Tel Aviv 69719 Israel > > > > Tel: +972-3-645-5220 > > Fax: +972-3-644-2903 > > Direct: +972-3-645-5273 > > sasha(a)radvision.rad.co.il > > *********************************************** > > > > > > >

3 2

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

15 Dec '00

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

1 0