- sg16-avd - lists.packetizer.com

[Federico.Tosco@CSELT.IT: SG 16 future meetings]
by Sakae Okubo 23 Sep '97

23 Sep '97

Return-Path: <Federico.Tosco(a)CSELT.IT> Return-Receipt-To: Tosco Federico <Federico.Tosco(a)CSELT.IT> Date: Fri, 19 Sep 1997 17:30:30 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> Subject: SG 16 future meetings To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>, "DeGrasse, Bruce" <b.degrasse(a)mci2000.com>, "Geary, Tom" <tom.geary(a)nb.rockwell.com>, "Okubo, Sakae" <okubo(a)gctech.co.jp>, "Robin-… [View More]

1 0

Re: TD-27 text for h.323
by Pete Cordell 23 Sep '97

23 Sep '97

Gary, I forgot to mention where I thought TD-27 text should go. I think the best place for it would be 8.4.6 (a new section in the Sunriver version) after the MC cascading part. This brings it in as part of Phase D: Call Services. Of the other options you mentioned, the first seems a bit tutorially, and the second is too early in the sequence of events. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 … [View More]1473 645499 ================================= >---------- >From: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- > [View Less]

1 0

Re: reRouteIndication
by Scott Petrack 23 Sep '97

23 Sep '97

I think I understand, thanks for the clarification. (Of course maybe the next sentence will prove that I don't understand ;-)): I did not want to change anything about either the dummy/empty issue nor the *content* of the reRouteIndication issue. I was just saying that IF {there are possibilities for the h323-message-body that don't appear in the UUIEs-requested structure in TD-28a} then {these new types should be added to the UUIEs-requested structure mentioned in TD-28a} We … [View More]agreed to allow a GK to monitor what an endpoint does in this way, and I just wanted it to be complete. Please let me know if this doesn't make sense (and I didn't understand). Scott pete.cordell(a)BT-SYS.BT.CO.UK on 09/22/97 12:56:49 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: reRouteIndication Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg > [View Less]

1 0

New Mailing List for H323-URLs
by Scott Petrack 22 Sep '97

22 Sep '97

As discussed at the recent rapporteurs meeting in SunRiver, we have opened a new mailing list (reflector) to be devoted to the subject H.323 URLs. It is called h323-url(a)vocaltec.com. To subscribe, you send mail to: h323-url-request(a)vocaltec.com and put subscribe in a line of the message. It makes no difference what the subject line is. 2. If you want to subscribe to a different address than the return address, you put subscribe userid(a)domain.name on a line of the body of the letter. … [View More]

1 0

Re: H.450.x ASN.1 Modules
by Corey Gates 22 Sep '97

22 Sep '97

Karl, > There is one remaining error on line 142 in a module copied from original > X.880. For some reason the ASN.1 compiler complains that the "opcode" is > not defined, even though the same construct does not have an error on line > 109. > In order to get the H.450 ASN.1 code to compile we commented this reference > temporarily. > In order to test the code take the comment on line 142 out. > If somebody has an idea what causes this problem please report to me as > … [View More]

1 0

Re: New draft of H.245
by Corey Gates 22 Sep '97

22 Sep '97

Dear Colleagues, Below are some comments on the latest draft H.245, ordered by page number, not importance: - (Page 8) Should we add some clarification about extension to the description of the Capability Exchange? Here is some text that could be added to the end of the first paragraph: "When a capability is received which contains extensions not understood by the terminal, the capability shall be accepted as if it did not contain the extensions." What do people think? - (Page 29) Since we … [View More]

2 1

Re: reRouteIndication
by Pete Cordell 22 Sep '97

22 Sep '97

Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger … [View More]sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg > [View Less]

3 2

H.323V2 draft
by gthom 22 Sep '97

22 Sep '97

All, H323v2i.doc has been uploaded to the gctech ftp site. It is complete except for the text on empty capability sets (TD-27) and Annex C on H.323 over ATM. Let me know if any of your changes have been missed, or have not been incorporated properly. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/22/97 Time: 08:57:14 -------------------------------------

1 0

Re: TD-27 text for h.323
by Pete Cordell 22 Sep '97

22 Sep '97

Gary, Generally I think your editorial intervention has been good. However, the state reset to when an non-empty capability set is received should be the state that H.245 is in after H.245 is originally established, NOT the state before the pause is invoked. This flushes out any H.245 state so that you have a known state to which to connect to a new endpoint. Some attempt at words is: On reception of a non-empty capability set in this paused state an endpoint shall reset its H.245 state to … [View More]that which it is in just after the H.245 transport connection is made at call establishment time (i.e. the beginning of phase B). Hope this helps, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- > [View Less]

1 0

List of Sunriver meeting participants
by Sakae Okubo 21 Sep '97

21 Sep '97

Dear Q.12-14/16 Sunriver meeting participants, Attached please find the list of participants for the Q.12-14/16 Rapporteur meeting in Sunriver. This has been made according to the sheet left at the meeting site and my recollection. Please advise me if your name is missing or anything is wrong with your entry. It will be included in the meeting report APC-1327. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication … [View More]Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Country Company Name E-Mail Germany Siemens Robert robert.callaghan(a)siemenscom.co Callaghan m Germany Siemens Istvan istvan.sebestyen(a)mch.pn.siemen Sebestyen s.de Germany Siemens Karl karl.klaghofer(a)mch.pn.siemens. Klaghofer de Germany Siemens Wolfgang Wofgang.Klasen@mchp. Klasen siemens.de Germany Siemens Markku korpim(a)scn.de Korpi Germany Siemens Martin.Euch martin.euchner(a)mchp.siemens.de ner Germany Teles Joerg Ott jo(a)teles.de Canada Mitel Terry Tam tamt(a)software.mitel.com Canada Mitel Dave Walker dave_walker(a)mitel.com Canada Nortel Nancy ngreenet(a)nortel.ca Greene Canada Nortel Tom Taylor taylor(a)nortel.com Canada Nortel Vahe balabani(a)nortel.ca Balabanian Korea ETRI Dong-Bum dbjung(a)winky.etri.re.kr Jung Korea Korea Sang-Gil sgk(a)ktweb.kotel.co.kr Telecom Kim Korea Korea Jung-Ja Roh jjroh(a)rcunix.kotel.co.kr Telecom USA 8*8 Hardish hardish(a)8x8.com Singh USA Ascend Dale Skran Dale.Skran(a)ascend.com USA AT&T Baldine- baldine(a)reserach.att.com Brunel Paul USA Cisco Greg ggoodkni(a)cisco.com Systems Goodknight USA DataBeam Bill Quinn bquinn(a)databeam.com USA DataBeam Pat Galvin pgalvin(a)DataBeam.com USA Delta Inf. Gary Thom GTHOM(a)DELTA-INFO.COM Systems USA FVC Corey Gates corey(a)fvc.com USA Intel Narjala narjala-bhasker@ Bhaske ccm.jf.intel.com USA Intel Chris Chris_Hansen@ ccm.jf.intel.com Hansen USA Intel Vineet vineet_kuman(a)ccm.jf.intel.com Kumar USA Intel Jim Toga jtoga(a)ibeam.intel.com USA Intel John H. john_h_wilson(a)ccm.jf.intel.com Wilson USA Lucent Andy adfranklin(a)lucent.com Technologies Franklin USA Lucent Glen ggf(a)lucent.com Technologies Freundlich USA Lucent Li Yan lyan(a)lucent.com Technologies USA Lucent Zhongjin zjyang(a)lucent.com Technologies Yang USA Microsoft Toby Nixon tnixon(a)microsoft.com USA PictureTel Kaynam knedayat(a)pictel.com Hedayat USA PictureTel Mark Reid reid(a)pictel.com USA STARVISION Don Piercy dpiercy(a)starvision.com USA VideoServer George gkajos(a)videoserver.com Kajos USA VTEL Michael cpchen(a)vtel.com Chen Finland Nokia Frank Fu frank.fu(a)nmp.nokia,com France Alcatel Bahman Mobasser France France Isabelle haiqnere(a)cnet.francetelecom.fr Telecom/CNET Haiqnere France France Jean-Pierre jean.pierre.blin@ Telecom/CNET Bin cnet.francetelecom.fr France France Christian christian.wipliez@ Telecom/CNET Wipliez cnet.francetelecom.fr Israel Accord Roni Even roni_e(a)accord.co.il Israel RADVision Amotz Shemi amotz(a)radvision.rad.co.il Israel RADvision Orit Levin orit(a)radvision.ard.co.il Israel Vocaltec Scott petrack(a)vocaltec.com Petrack Israel Vocaltec Gur Kimchi gur(a)vocaltec.com Japan Fujitsu Yoshitsugu yn(a)marvel.ts.fujitsu.co.jp Nishizawa Japan GCL Sakae Okubo okubo(a)gctech.co.jp Japan KDD R&D Labs Shigeyuki sakazawa(a)lab.kdd.co.jp Sakazawa Japan KDD R&D Labs Hideaki hd-yamada(a)kdd.co.jp Yamsda Japan NEC Hidenobu harasaki(a)dsp.cl.nec.co.jp Corporation Harasaki Japan NTT Hiroshi koyano(a)nttvdt.hil.ntt.co.jp Koyano Netherl KPN Jeroen de j.h.demuijnck(a)research.kpn.com ands Muijnck Norway Telenor Helge Helge.Sandgrind(a)fou.telnor.no Sandgrind UK BT Labs John J.boucher(a)bt-web.bt.co.uk Boucher UK BT Labs Pete Pete.Cordell(a)bt-sys.bt.uk Cordell UK BT Labs Mike nilsson_m_e(a)BT-WEB.BT.CO.UK Nilsson Sweden Ericsson Anders anders.svennevik(a)ebc.ericsson. Svennevik se Switzer IBM H. Linh hlt(a)zurich.ibm.com land Truong [View Less]

1 0