October 1998 - sg16-avd - lists.packetizer.com

Re: H.245 V5 determined
by Mike Nilsson 07 Oct '98

07 Oct '98

Apologies for causing confusion. As pointed out in the attached, determined version 5 should have been created from TD39(PLEN) AND TD28(PLEN). I have now uploaded the corrected document. Mr Okubo : please remove the zip file that you created yesterday. Best regards Mike Nilsson *********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Real Time Internet Group Fax: +44 1473 645011 * * Applications and Middleware Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [B54 Room 94] * * Martlesham Heath * * Ipswich IP5 3RE * * UK * *********************************************************************** Dear Mr. Mike Nilsson, >I have uploaded the document H245DELG.DOC to the ftp site. This is the >delta document that was determined as version 5 of H.245. In this document, items in TD39(PLEN) are contained but other items approved as H.245 ver.5 determination described in the separate TD (TD28(PLEN)) are not included. Can I ask the status of this document? Is this to reflect all items approved as H.245 ver.5 determination? Or is this for some but not all items approved for the determination as in TD39(PLEN)? In the former case, TD28(PLEN) should be reflected in the document. In the latter case, separate document should be provided to reflect all the approved items for the H.245 determination. I can work for the items in TD28(PLEN). Would you please tell me the status for the clarify and to help the editorial work on H.245 text? Best regards, ---- Yoshihiro Kikuchi E-mail: kiku(a)eel.rdc.toshiba.co.jp Research and Development Center TEL: +81 +44 549 2151 Toshiba Corp. FAX: +81 +44 520 1308 >---------- >From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] >Sent: 07 October 1998 07:25 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: H.245 V5 determined > >Dear Q.12-14/16 experts, > >M Nilsson> I have uploaded the document H245DELG.DOC to the ftp site. >M Nilsson> This is the delta document that was determined as version 5 >M Nilsson> of H.245. >M Nilsson> >M Nilsson> Version 4 of H.245 was approved without any changes to COM- >M Nilsson> 59. > >This delta file has been zipped and moved to the following place: > > ftp://standard.pictel.com/avc-site/9809_Gen/H245delg.zip > > >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

H.245 V5 determined
by Sakae OKUBO 07 Oct '98

07 Oct '98

Dear Q.12-14/16 experts, M Nilsson> I have uploaded the document H245DELG.DOC to the ftp site. M Nilsson> This is the delta document that was determined as version 5 M Nilsson> of H.245. M Nilsson> M Nilsson> Version 4 of H.245 was approved without any changes to COM- M Nilsson> 59. This delta file has been zipped and moved to the following place: ftp://standard.pictel.com/avc-site/9809_Gen/H245delg.zip 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

Re: Output/Input Documents of the SG16 meeting
by Mike Nilsson 06 Oct '98

06 Oct '98

I have uploaded the document H245DELG.DOC to the ftp site. This is the delta document that was determined as version 5 of H.245. Version 4 of H.245 was approved without any changes to COM-59. Best regards Mike Nilsson *********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Real Time Internet Group Fax: +44 1473 645011 * * Applications and Middleware Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [B54 Room 94] * * Martlesham Heath * * Ipswich IP5 3RE * * UK * *********************************************************************** >

1 0

Fwd: h341 determined on Picturetel site
by Sakae OKUBO 05 Oct '98

05 Oct '98

Dear Q.12-14/16 experts, George Kajos> I uploaded H341det.doc and H341det.zip to the Picturetel site. George Kajos> The document George Kajos> contains all changes requested at eh Study Group meeting. H341det.zip has been moved to the following place: ftp://standard.pictel.com/avc-site/9809_Gen/H341DET.ZIP 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

Re: Draft H.323 Annexes E and F uploaded
by Kaynam Hedayat 05 Oct '98

05 Oct '98

Kishore, The duplicate packet over UDP might be due to a lost response packet. In that case you must send the original response. I am not sure what you mean by dropping the Q.931 headers. All of H.225.0 is carried over UDP. Kaynam Kishore Babu Ramisetty <kish(a)TRILLIUM.COM> on 09/29/98 03:16:20 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Kaynam Hedayat/PicTel) Subject: Re: Draft H.323 Annexes E and F uploaded Hi Folks, Annex E -- sections E.2.3 and E.5.3 are contradictory. section E.2.3 >NOTE: It is possible in the above scenario to get duplicate PDUs over TCP and >UDP. The Annex E. compliant application shall treat such an occurrence the >same way it treats duplicate UDP PDUs. section E.5.3 >If the request is a duplicate of a message formerly received via TCP, it shall >be silently ignored. If the request is a duplicate of a message formerly >received via UDP, the response given to the original request message shall be >retransmitted immediately and the currently active timer (see below) shall be restarted. Assuming section E.5.3 is correct, why should the duplicate PDUs get a different kind of treatment when received via UDP? Is there any reason why the duplicate PDU received via UDP cannot be ignored? Also, I would appreciate if someone can enlighten me of the reasons for dropping Q.931 headers from the messages sent via UDP? For eg. The rate multiplier etc. in Q.931 setup could be used for interworking with SCN. (Is it now done via h323-uu-pdu itself?) Thanks, -Kishore. > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Rahul Chopra > Sent: Monday, September 28, 1998 2:51 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Draft H.323 Annexes E and F uploaded > > > Joerg: > Where is the avc-site? > Would apprecate a pointer > Thanks. > Rahul > > > -----Original Message----- > > From: Joerg Ott [SMTP:jo@INFORMATIK.UNI-BREMEN.DE] > > Sent: Monday, September 28, 1998 5:35 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Draft H.323 Annexes E and F uploaded > > > > Folks, > > > > I have uploaded the determined documents H.323 Annex E and > > H.323 Annex F into the Incoming directory of the AVC ftp site. > > The file names are: > > > > H323-AnnexE-4.02.doc (equivalent to TD-47/PLEN) > > H323-AnnexF-03.doc (equivalent to TD-51/PLEN) > > > > Joerg >

1 0

Mr. Tosco report of WP2/16
by Sakae OKUBO 05 Oct '98

05 Oct '98

Dear Q.12-14/16 experts, Please be advised that Mr. Tosco's report of WP2/16 of the September SG16 meeting has been placed at the following: ftp://standard.pictel.com/avc-site/9809_Gen/Tosco_WP2_report.zip 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

Output/Input Documents of the SG16 meeting
by Sakae OKUBO 05 Oct '98

05 Oct '98

Dear Q12-14/16 experts, I have moved all the files in the Incoming directory to the following: ftp://standard.pictel.com/avc-site/9809_Gen or http://standard.pictel.com/ftp/avc-site/9809_Gen Please see /9809_Gen/9809_Gen.html for the index. Editors are requested to upload the final documents for the interested parties. 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

Re: About H.323 interoperating with ss7
by Ami Amir 02 Oct '98

02 Oct '98

Krishna Attached are the two relevant ones. Ami -----Original Message----- From: Krishna Kurapati [SMTP:kkrishna@ipcell.com] Sent: Thursday, October 01, 1998 5:28 PM To: 'Ami Amir'; Matt Holdrege Cc: Guocai Deng; iptel(a)lists.research.bell-labs.com Subject: RE: About H.323 interoperating with ss7 Dear Ami, Thanks for the information. Is there a mailing-list for participating in this ITU activity ? Thanks Krishna Kurapati IPCell Technology, Inc 2011 North Collins Blvd Suite 707 Richardson TX 75075 (972) 671 2355 -----Original Message----- From: Ami Amir [SMTP:amir@radvision.rad.co.il] Sent: Wednesday, September 30, 1998 8:23 AM To: Matt Holdrege Cc: Guocai Deng; iptel(a)lists.research.bell-labs.com Subject: Re: About H.323 interoperating with ss7 Hi At the last SG 16 H.323 meeting in Geneva - the IPDC documents were submitted - and based on those inputs and discussions during the meeting, it was agreed that a "work item" be created around the concept that gateways may be decomposed inot two elements - High Level Control, and an assembly of media gateways with "Low Level Control". The concept was driven in part by the realization that in public network, SS7 or similar non-associated signaling networks, there is a need to provide a solution where the SS7 like signaling will interface to the High Level Gateway Control, which will then - via a high level to low level protocol - control the media streams and gateway connections. The plan is to work on this work item before and during the next meeting (scheduled for November in Torino, Italy). Ami Matt Holdrege wrote: > > ---------- > > From: Matt Holdrege[SMTP:MATT@ASCEND.COM] > > Sent: Wednesday, September 30, 1998 1:01:54 PM > > To: Guocai Deng > > Cc: iptel(a)lists.research.bell-labs.com > > Subject: Re: About H.323 interoperating with ss7 > > Auto forwarded by a Rule > > > At 10:14 AM 9/30/98 +0800, Guocai Deng wrote: > > Who can tell me how H.323 network interoperating with SS7 network ? > >it maybe important to support supplementary services and one stage dial. > > We are working on this issue in various standards bodies including the > IETF, ITU-T, ETSI and other forums. IETF drafts include: > > draft-greene-ss7-arch-frame-00.txt > draft-ong-rsgp-ss7-info-00.txt > draft-huitema-sgcp-v1-02.txt > draft-taylor-ipdc-00.txt > draft-elliott-ipdc-media-00.txt > draft-dugan-ipdc-connection-00.txt > draft-bell-ipdc-signaling-00.txt > draft-pickett-ipdc-management-00.txt > > And I'm sure we will see more before the next IETF meeting. We may see some > new IETF working groups on this topic by then as well. > > --------- > This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List. --------- This message came from the IETF IPTEL Working Group Mailing List.

1 0

Re: H.332 uploaded into the Incoming directory of the avc ftp sit e
by Kumar, Vineet 01 Oct '98

01 Oct '98

ftp://standard.pictel.com/avc-site/Incoming/ vineet > -----Original Message----- > From: Spencer Hu [SMTP:Spencer.Hu@GDC.COM] > Sent: Wednesday, September 30, 1998 4:26 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.332 uploaded into the Incoming directory of the avc > ftp site > > Spencer Hu@GDC > 09/30/98 07:26 AM > > DO YOU HAVE A WEB ADDRESS, PLEASE? > > > SPENCER > > ------ > > > > > "Kumar, Vineet" <vineet.kumar(a)intel.com> on 09/29/98 05:53:30 PM > > Please respond to Mailing list for parties associated with ITU-T Study > Group 16 <ITU-SG16(a)mailbag.cps.intel.com> > > To: ITU-SG16(a)mailbag.cps.intel.com > cc: (bcc: Spencer Hu/Engineering/GDC/US) > Subject: H.332 uploaded into the Incoming directory of the avc ftp site > > > > > I have uploaded the decided version of H.332 (h332.doc) and the approved > version of the Implementers Gudie (h323ImplGuide.doc) into the Incoming > directory of the avc ftp site. > vineet > -------------------------------------------------------------------------- > - > - > -------------------------- > Vineet Kumar vineet.kumar(a)intel.com > Intel Corporation, JF3-212 (+1) 503-264-3439 > (phone) > Hillsboro, OR 97124-5961 (+1) 503-264-3375 > (fax) > -------------------------------------------------------------------------- > - > - > --------------------------

1 0

Re: Overlapped Sending and LRQ
by Chris Purvis WVdevmt-WS 01 Oct '98

01 Oct '98

Sarah, The overlapped send section as I understand it is predicated on the following assumptions: 1. A number that is incomplete can not also be complete! If this guideline is not followed, an endpoint in a zone separate from those of the two endpoint 1234 and 12345 (say) that attempts to dial a number one digit at a time will NEVER be able to get through to 12345! 2. Numbers are unique. 3. A gatekeeper will know from the format and first part of a number how long it should be. For example a gatekeeper might assume that if a number is not in its own zone (and therefore known by it) then to stand any chance it will have to be a full international number, whose format and length are specified in E.164. Public numbering plans do need to be covered as part of the Annex G effort, if we are going to attempt to do anything meaningful there with phone number-type addresses (as opposed to emailid-type addresses). Unfortunately the political minefield is considerable. In the meantime some sort of special knowledge on the part of each gatekeeper is assumed. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0