March 1999 - sg16-avd - lists.packetizer.com

FW: Where H.245 goes - MG or MGC
by Tom-PT Taylor 08 Mar '99

08 Mar '99

> -----Original Message----- > From: David R. Oran [SMTP:oran@cisco.com] > Sent: Monday, March 08, 1999 10:25 AM > To: megaco > Subject: Where H.245 goes - MG or MGC > > Here are some random thoughts on one of the questions of marrying Megaco > with H.323 - where H.245 goes. Some prior messages have indicated that > there are tradeoffs involved here, and I agree. Some food for thought: > > - If we terminate H.245 on the MG, this blows away V2 fast start, and > looking at likely call flows may introduce 1/2 RTT extra over a monolothic > H.323 gateway. > > - The MGC may wish to participate in CAPs exchange for policy reasons. > > - The H.245 open logical channel operation is analogous to doing VC > establishment on the MG in the ATM case, and for parallelism might be best > done MG-MG. It is also where certain resource allocation operations get > done and hence synchronizes well with the H.323 model of error reporting. > Unfortunately, putting CAPs excahnge in one association and logical > channel control in a different association would be a pretty major tweak > to H.323. > > - Putting H.245 completely on the MG factors the problem of translating > among different media description syntaxes (e.g. H245/ASN1 vs SDP) - the > MGC-MG protocol then might not need to have a full-blown media description > in it when using H.323 for global signaling. > > - Putting H.245 on the MG gives the MG a lot of autonomy. This is arguably > more autonomy than the Megaco model should assign to the MG. > > - Splitting up H.323 with H.225 signaling in one place and H.245 signaling > in another place may uncover some state coordination issues which would > (unneccesarily?) complicate the MGC-MG protocol and possibly introduce > direct H.323 dependencies. > > My intuition says that the tradeoffs favor keeping H.245 in the MGC. What > do others think?

1 0

Re: TPKT in H.225.0
by Derks, Frank 08 Mar '99

08 Mar '99

Hi Greg, thanks for pointing that out. I was not aware of TPKT being described in any ITU-T recommendation. So rather than adding some text to H.225.0 to define/describe TPKT, it would be better to add explicit references to T.123 in the text of H.225.0 in those places where TPKT is mentioned. Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | ----------------------------------------------------- -----Original Message----- From: Greg Goodknight [mailto:ggoodkni@CISCO.COM] Sent: 05 March 1999 20:45 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: TPKT in H.225.0 I'm just now plowing through old mail. Sorry to have not caught this thread sooner. TPKT is also defined in T.123 which is called out in H.225.0/2.2 Greg Goodknight Cisco Systems -----Original Message----- From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, February 04, 1999 5:17 AM Subject: Re: TPKT in H.225.0 >Hi Tom, > >I couldn't find it either and I suspect that it couldn't be in because the >ITU is very reluctant to reference any non-ITU material. Furthermore, >RFC1006 encompasses a lot more than just the bit(s) that are used for >H.225.0, so even referring to this RFC does not clarify it all. I think some >work should be spent on this. > >Frank > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: 02 February 1999 22:12 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: TPKT in H.225.0 > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I >can't find it there now. > >> -----Original Message----- >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] >> Sent: Tuesday, February 02, 1999 4:05 AM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> Hi Paul, >> >> I received two responses to my question, one from you and one from Tom >> Taylor. The fact that there are at least two people that know about it >> (and >> several dozens more that have actually implemented the protocol stacks), >> makes it hard to believe that this is an "oversight" in the >> recommendation. >> In fact, not knowing about this makes it impossible to implement an >> interoperable protocol stack! Shouldn't action be taken to get this into >> the >> recommendation ASAP (e.g. through the Implementor's Guide)? >> >> Regards, >> >> Frank >> >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 01 February 1999 18:50 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that >> has >> never been fixed in the Recommendation. >> >> Paul Long >> Smith Micro Software, Inc. >

1 0

Santiago meeting
by Sakae OKUBO 08 Mar '99

08 Mar '99

/// This is more informative than my previous posting /// Date: Mon, 08 Mar 1999 11:17:12 +0100 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>,"DeGrasse, Bruce" <b.degrasse(a)mci2000.com>,Freundlich <ggf(a)lucent.com>, "Geary, Tom" <tom.geary(a)CONEXANT.COM>,"Okubo, Sakae" <okubo(a)giti.or.jp>,"Robin-Champigneul, Yves" <yves.robinchampigneul(a)cnet.francetelecom.fr>,"Skran, Dale" <Dale.Skran(a)ascend.com>,"Thom, Gary" <gthom(a)delta-info.com> MIME-version: 1.0 Dear all, I remember you some relevant issues that I already mentioned in some previous e_mails: * Logistic information is available at http://www.ict.uchile.cl/itut.sg16/ Please note that hotel reservation deadline (March 31). The hotel reservation form is included in the ITU-T collective letter (see below) Please be sure to reserve your flights well in advance. * The ITU-T collective letter is available at http://www.itu.int/itudoc/itu-t/com16/coll/index.html Please note the deadline for delayed contributions (May 5). The meeting registration has to be sent, as usual, to ITU, by April 17. Best regards Federico CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel.: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it

1 0

Re: Invitation via Gatekeeper
by Truong Hong-Linh 08 Mar '99

08 Mar '99

Chris, my comments are marked with <Linh> Regards, Linh ---------------------------------------------------------------------------- --- PLEASE READ IF YOU CARE ABOUT EITHER GATEKEEPERS OR CONFERENCES!!! Linh and I appear to agree that we need the views of more interested parties! Linh, > >2. I disagree with Linh's assertion that "an MC never sends > ARQ". If I am > >administering an MCU which can initiate conferences by > calling up a list of > >participants at a given time, I will certainly require that > MCU to apply to > >its gatekeeper for permission to make these calls. > >In the particular case under discussion, E2/its MC certainly > has to send > >ARQ. It is going to make a call, which will result in data > flowing its > >gatekeeper's zone, and which may end up costing money. > >E1's "call" does not result in data flowing in its > gatekeeper's zone if the > >centralised model is used for data (in which I include both audio and > >video) and it happens to be in a different zone from E2/MC > and E3 - so > >maybe E1 doesn't have to send ARQ? However it will result > in data flowing > >in its gatekeeper's zone if the decentralised model is used > for data, and > >the MC may wish to (cross?) charge E1 for inviting E3, so > maybe E1 does > >need to send ARQ. > > I must admit that I only consider the "address resolution" > part of the ARQ > procedure. I did not consider its BW management and reservation part, > because that part is in my view broken. I'd never use the ARQ for that > purpose. An endpoint only knows about the needed BW when a > logical channel > is opened, and not at call setup time! And that applies > already in case of a > point-to-point call. Since it does not work for > point-to-point cases, it > will also not work for the conference cases. I agree that the bandwidth stuff is broken. However, if a gatekeeper chooses to do things with it, you're going to end up with interoperability problems from saying you don't use it. The point is slightly wider, though, that someone needs to have knowledge of whether a given user is authorised to initiate the inviting of people to conferences. I'd rather have all my configuration for that sort of thing in my gatekeeper than in the (potentially multiple) MCs in its zone. <Linh>I didn't say that I don't use the ARQ procedure. I need it for address resolution purpose. I only want to say that the BW management part of the ARQ procedure is broken. > To make the scenario a bit more complicated, assume there is already a > conference between E1, E2/MC and E4. Now E1 wants to invite > E3. E4 will only > knows about the joining of E3 when it is requested by the MC to either > re-open the logical channels (centralized case with codec > change) or open > new ones (distributed case). Really? I thought that was what the conferenceIndication "terminalJoinedConference" was for, and that the MC was supposed to send it to all participants whenever anyone new joined the conference. <Linh> You're rigth. I was thinking about the BW stuff. > Should E4 sends ARQ when it is > requested to > open the logical channels? I don't think that is actually specified. > Furthermore, how should E4 ask its GK for the permission to > have a call with > E3? I don't know whether the BRQ procedure can help. Maybe > somebody more > knowledgeable could help to clarify the situation. In my view, the calls are logically between each endpoint and the MC, and this is how the control paths run. Yes the model is slightly broken for data paths, particularly by by decentralised conferences. > >3. The destCallSignalAddress given in ACF is the only > address to which an > >endpoint should send a setup message. I find it hard to > agree with Linh's > >assertion that on the basis of an ACF mentioning E3, E1 > should send a setup > >message to E2/MC. The suggestion in the case of the > gatekeeper routed > >model is simply impossible. E1 doesn't know where E2/MC is, > so I fail to > >see how E1 can send its setup message to E2/MC in this case. > Note that all > >E1's call signalling goes to its gatekeeper - and as a > routing gatekeeper I > >would feel justified in ensuring that E1 doesn't find out > where E2/MC is: > >for instance I wouldn't feel obliged to leave > mcLocationIndication messages > >alone as I relay them. The upside of this is that at least then E1's > >gatekeeper knows where the activeMC is, and should be able > to work out > >what's going on when the setup message comes in. > > I was assuming that the call between E1 and E2 was direct and > the MC was > already created at E2. Otherwise, if the call was GK-routed > then according > to H.323 Section 8.4.3.4 the GK would know where the MC is, > and certainly E1 > would have to sends its SETUP to the GK/MC as specified in 8.4.3.5. Fair-ish cop... For some of it (ie the GK routed stuff). It kind of depends on your understanding of a GK having "access to" an MC. Does any entity with MC functionality that's registered with a GK count as an MC to which it "has access"? Or just ones that happen to be involved in this call? This is an area in which the standard is terribly woolly. <Linh>Agree. We need clarification. (BTW do you think that it is the only area? ;-) ) Can I just clarify your position, please? If I understand you correctly you're suggesting that if I as an endpoint want to send a setup "towards" the active MC in my call or conference in order to invite a new party to the conference, I don't need to send ARQ to my gatekeeper. In any other circumstances I need to send ARQ and receive ACF before I may send Setup. In the gatekeeper routed model, any setup message with conference goal "invite" will be sent by the gatekeeper to the active MC for the conference whose conferenceID matches that in the setup message UNLESS it comes from that entity, in which case it will go to the desired destination. <Linh>No. In my view, if an endpoint wants to invite a new party, it has to send ARQ to its GK. Then it shall send the SETUP mesage with the address info contained in the ACF to the MC. The MC will then route that SETUP accordingly, i.e. to the GK in the GK-routed case or to the destination endpoint in the direct case. Arising questions: What if there is NO active MC (ie the call is a typical one)? How do I promote a call to a conference in the direct-routed model where I've ended up as "slave" in the master-slave determination procedure (where other entities in the call may or may not contain MCs)? <Linh>With the terminal capabilty set exchange, you _know_ whether the remote endpoint is MC-capable or not. If yes you send the invite SETUP to the remote endpoint which then creates an MC. If no then tough luck the call cannot be promoted to a conference. Who is vetting the inviting endpoint's right to invite (certainly the GK's job in my opinion, whatever routing model you're using). Regards, Chris

1 0

SG16 Santiago meeting
by Sakae OKUBO 08 Mar '99

08 Mar '99

Dear Q.12-14/16 experts, This is pointer information from Mr. Tosco, Chairman of WP2/16 regarding the Santiago meeting of SG16 next May. Collective letter http://www.itu.int/itudoc/itu-t/com16/coll/005.html Logistic information http://www.ict.uchile.cl/itut.sg16/ Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Revised Monterey meeting report APC-1554a
by Sakae OKUBO 08 Mar '99

08 Mar '99

Dear Q12-14/16 Monterey meeting participants, I have replaced the draft meeting report APC-1554.zip with a revised version APC-1554a.zip at the /9902_Mon directory. Some editorial improvements have been made: - Improvements on the parts relevant to the text conversation and text SET as requested by Mr. Hellstrom, - Addition of the list of participants - Addition of Amendment 5 to H.222.0 in the Q12 future plan - Some other purely editorial corrections Using this opportunity, let me remind the Annex D to H.323 collaborators of the following action: "TD-39 contains the proposed liaison response. Mr. Ott, Mr. Kumar, and Mr. Draper will help Mr. Skran finalize the text as authorized by the meeting." Once this has been confirmed, I will issue revision 2 with confirmed status and send its copies to Mr. Tosco and Mr. Bigi. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

FYI: Travel to Chile
by Dale L. Skran 07 Mar '99

07 Mar '99

All: Some concern was raised about being let into Chile and needed a yellow fever shot to leave. This does not appear to be the case. Dale Skran Q13 Rapporteur >From: Eileen.Patterson(a)ascend.com >X-Lotus-FromDomain: ASCEND >To: Dale.Skran(a)ascend.com >Date: Thu, 4 Mar 1999 12:10:32 -0800 >Subject: Travel to Chile > > > >To travel to Chile you will need...a valid passport, $45 entrance fee to >the country, and nothing else. >I spoke with the State Department (202-647-5225). They say to use common >sense precautions in Chile...stay away from demonstrations by Chileans. US >citizens are not at risk unless they get involved in these demonstrations. > >The Chilean Embassy (202-785-1746) assured me that no immunizations were >necessary for travel to Chile or exiting from Chile. > > > >

2 1

Re: Invitation via Gatekeeper
by Chris Purvis 05 Mar '99

05 Mar '99

Radhika, Gary, H.323v2, section 6.7: "The MCU is an endpoint which provides support for multipoint conferences. The MCU shall consist of an MC and zero or more MPs." Note that the phrase used is "consist of", not "contain". If an MCU is an endpoint, it is callable (I think we're agreed on that). If it consists of an MC and zero or more MPs, that means it must still be callable when it consists of only an MC. Therefore the MC is the part of an MCU that is callable. Hence an MC MAY be a callable entity. The wider point is that my understanding was that all control signalling done by an MCU was done by the MC part of it (again on the basis of those two sentences). If this is inconsistent with other parts of the standard, then it certainly needs to be fixed (please give references); if it is consistent with the rest of the standard, but not what was intended, then we need to reconsider what we really want. For the case under discussion I'd agree with Gary that it's a minor semantic quibble (and as such I was planning to allow Gary's mail on its own to pass without comment), but if there's the possibility of it becoming more than that maybe we ought to clear it up. Regards, Chris > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: 05 March 1999 2:08 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Invitation via Gatekeeper > > > This was my understanding as well. > > Does anyone disagree with Gary? > > Regards, > Radhika > > ------------------------------------------- > > Radhika R. Roy > AT&T Labs > Room C1-2B03 > 200 Laurel Avenue S. > Middletwon, NJ 07748 > USA > + 1 732 420 1580 Tel > rrroy(a)att.com > > > -----Original Message----- > > From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] > > Sent: Friday, March 05, 1999 11:18 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Invitation via Gatekeeper > > > > I have this minor semantic clarification: > > > > > 2. I disagree with Linh's assertion that "an MC never > sends ARQ". If I > > am > > > administering an MCU which can initiate conferences by > calling up a list > > of > > > participants at a given time, I will certainly require > that MCU to apply > > to > > > its gatekeeper for permission to make these calls. > > > In the particular case under discussion, E2/its MC > certainly has to send > > > ARQ. It is going to make a call, which will result in > data flowing its > > > gatekeeper's zone, and which may end up costing money. > > > > The original idea was that only endpoints send ARQ. An MC is not an > > endpoint, however, it is a > > functional element which can be contained in an endpoint > (such is the case > > of an MCU or a terminal > > which contains an MC). So even though the endpoint contains > an MC, it is > > the endpoint which is > > sending the ARQ not the MC functional element. > > > > If an MC exists in the Gatekeeper, I do not beleive that > that MC will ever > > send ARQ for any of the > > connections in the conference. Only the endpoints in that > conference will > > send ARQ to their > > Gatekeepers. > > > > > > Gary > > ------------------------------------------------------ > > Name : Gary A. Thom > > Company: Delta Information Systems, Inc. > > Address: 300 Welsh Rd., Bldg 3 > > Horsham, PA 19044 USA > > Phone : +1-215-657-5270 Fax : +1-215-657-5273 > > E-mail : gthom(a)delta-info.com > > ------------------------------------------------------ >

2 1

Re: H.323/VoIP QoS
by Prasad Kallur 05 Mar '99

05 Mar '99

Hi Joon, Have you also, setup a web site for any discussion and document archival? Thanks, Prasad -----Original Message----- From: Joon Maeng [mailto:Joon_Maeng@VTEL.COM] Sent: Wednesday, March 03, 1999 8:49 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323/VoIP QoS Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail to majordomo(a)majordomo.vtel.com with a command line subscribe h323_voip_qos your email address in the body of the message and follows the instruction of the response from the majordomo. Any text in the subject will be ignored. If you have any problem in subscribing the list server, please email me. Thank you much for your interests. Regards, Joon

1 0

Re: TPKT in H.225.0
by Greg Goodknight 05 Mar '99

05 Mar '99

I'm just now plowing through old mail. Sorry to have not caught this thread sooner. TPKT is also defined in T.123 which is called out in H.225.0/2.2 Greg Goodknight Cisco Systems -----Original Message----- From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, February 04, 1999 5:17 AM Subject: Re: TPKT in H.225.0 >Hi Tom, > >I couldn't find it either and I suspect that it couldn't be in because the >ITU is very reluctant to reference any non-ITU material. Furthermore, >RFC1006 encompasses a lot more than just the bit(s) that are used for >H.225.0, so even referring to this RFC does not clarify it all. I think some >work should be spent on this. > >Frank > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: 02 February 1999 22:12 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: TPKT in H.225.0 > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I >can't find it there now. > >> -----Original Message----- >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] >> Sent: Tuesday, February 02, 1999 4:05 AM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> Hi Paul, >> >> I received two responses to my question, one from you and one from Tom >> Taylor. The fact that there are at least two people that know about it >> (and >> several dozens more that have actually implemented the protocol stacks), >> makes it hard to believe that this is an "oversight" in the >> recommendation. >> In fact, not knowing about this makes it impossible to implement an >> interoperable protocol stack! Shouldn't action be taken to get this into >> the >> recommendation ASAP (e.g. through the Implementor's Guide)? >> >> Regards, >> >> Frank >> >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 01 February 1999 18:50 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that >> has >> never been fixed in the Recommendation. >> >> Paul Long >> Smith Micro Software, Inc. >

1 0