- sg16-avd - lists.packetizer.com

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 02 Oct '98

02 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

Re: H.225.0 Annex G
by William Pimentel 01 Oct '98

01 Oct '98

Glen Freundlich wrote: > I have uploaded H.225.0 Annex G into the Incoming directory of the avc > ftp site. The ziped file is annexg.zip, which expands to annexg06.doc. > This is equivalent to TD-61/PLEN plus the modifications requested during > the plenary session. > > Glen > Is this the final and approved text? -- William Pimentel w-piment(a)uniandes.edu.co

2 1

Overlapped Sending and LRQ
by Sarah Lavie 01 Oct '98

01 Oct '98

According to Overlapped Sending recommendation "If there is insufficient addressing information in the ARQ, the Gatekeeper should respond with an ARJ with the AdmissionRejectReason set to incompleteAddress" The main question is how the Overlapped Sending scheme interacts with the LRQ scheme. Here are 2 example scenarios to explain the difficulties: A) overlapped numbering scheme in 2 zones -------> GK1 GK2 dial 1234 / \ / \ T1 = 12345 T2 = 1234 A terminal dials "1234". GK1 identifies the address as incomplete and sends ARJ. However, the caller wished to call terminal 2 and therefore the address was complete and GK1 should have sent LRQ. A.1 In this case, Does the terminal should send ARQ again? Does the last ARJ terminates the call in the caller side? A.2 Should the re-sending of the ARQ (if exist) be the trigger for sending the LRQ, from the GK point of view? B) Location Request mechanism does not support overlapped sending ----> GK1 ---> GK2 dial 1234 LRQ \ \ T2 = 12345 A terminal dials "1234" as part of the digit collection. GK1 somehow recognizes that the address should be referred to GK2. However GK2 returns an LRJ because the LRQ mechanism does not support overlapped sending. It seems to me that the Overlapped Sending should be deployed in systems where the numbering scheme is unified and predefined by zones, as it is in the telephony systems. In this case, LRQ should not be deployed. Am I right in this assumption? If not, what should be the guidelines for sending LRQ when Overlapped Sending mode is on. Regards, ============================== Sarah Lavie RadVision sarah(a)radvision.rad.co.il ==============================

1 0

Re: H.332 uploaded into the Incoming directory of the avc ftp site
by Spencer Hu 30 Sep '98

30 Sep '98

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

H.332 uploaded into the Incoming directory of the avc ftp site
by Kumar, Vineet 29 Sep '98

29 Sep '98

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

Determined H.450.x documents uploaded to pictel ftp site
by Klaghofer, Karl PN VS LP3 29 Sep '98

29 Sep '98

I have uploaded the following determined documents to the Incoming directory of the pictel ftp site (ftp://standard.pictel.com/avc-site/Incoming/) - H.450.4 Call Hold Supplementary Service for H.323 - H.450.5 Call Park and Call Pickup Supplementary Services for H.323 - H.450.6 Call Waiting Supplementary Service for H.323 - H.450.7 Message Waiting Indication Supplementary Service for H.323 The file names are H4504.zip (corresponds to TD34PLEN), H4505.zip (i.e. TD35PLEN), H4506.zip (i.e. TD36PLEN) and H4507.zip (TD40PLEN) respectively. Best Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. PN VS LP3 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

Usage guidelines for ITU-SG16
by L-Soft list server at Intel Corporation (1.8c) 29 Sep '98

29 Sep '98

Subject: Welcome to itu-sg16 (updated 1/6/97) Remember - to POST messages to the list send to: itu-sg16(a)mailbag.jf.intel.com - to interact with listserver.... send to: listserv(a)mailbag.jf.intel.com This reflector has now (as a second step) inherited the members currently registered at the h32z2-list(a)mtgbcs.lucent.com. This was done in a semi-automated fashion using the existing list as input to this one. If you do not desire to be on this list, my apologies - you may unsubscribe by sending a message to the list software at "listserv(a)mailbag.jf.intel.com" with the body set to signoff itu-g16 In addition it is requested, that contact information be provided so that the current list of correspondents on this list be provided to ITU-TSB if so requested. [Full Name] [Organization] [contact number] Please send this information in the body of a message to 'jtoga(a)ibeam.intel.com', set the "subject" of the mail to "SG16 Contact". Listed below are some hints on interacting with this mailing list: **************************************************************************** ************** mail reflector: (sent to listserv(a)mailbag.jf.intel.com) Subscribe: BODY of the text set to subscribe itu-sg16 <your email address> <your name> Unsubscribe: signoff itu-g16 You can get more information on commands by sending a message with the body of the message containing either 'help' or 'info' to: listserv(a)mailbag.jf.intel.com List Digests: If you feel like you lost some list messages or simply want to get a chronological chunk of them, you can do so. send a message to "listserv(a)mailbag.jf.intel.com" with the body of the message index itu-sg16 This will get you a list of all the digest files. After choosing which files you want, send another message to "listserv(a)mailbag.jf.intel.com" with the body of the message get itu-sg16 [filename] Finally you may always contact me (via any of the methods in my signature) with any questions. jimt. ************************************************************************* *** 503.264.8816(voice) 503.264.3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *************************************************************************

1 0