- sg16-avd - lists.packetizer.com

H.225 white draft
by Terry L Anderson 07 Aug '00

07 Aug '00

I am looking over the "GenericData" related fields in the ASN.1 and saw one asymmetry. Several commands (e.g., Alerting, ARQ, etc) contain featureSet FeatureSet OPTIONAL while Setup contains neededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, desiredFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, supportededFeatures SEQUENCE OF FeatureDescriptor OPTIONAL, which with the exception of the replacementFeatureSet BOOLEAN is exactly the contents of FeatureSet. Is there a reason for having these separately in Setup rather than having featureSet in Setup? -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

3 4

Re: Important Portland Meeting Details & Late Fees
by Sebestyen Istvan ICN M CS 27 05 Aug '00

05 Aug '00

Dear Colleagues, please do sign up quickly. We can not leave Intel and ourselves "in the rain". Also attendies should please not go to stay elsewhere, if someone is thinking to do this, as again the meeting preparation plan of Intel collapses. If we get into difficulties, first people staying elsewhere should pay first the meeting fee. Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, 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.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/standards ---------------------------------------------------------------------------- ---------------- > ---------- > From: Meyer, Greg W[SMTP:greg.w.meyer@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, August 04, 2000 8:40 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Important Portland Meeting Details & Late Fees > Importance: High > > Q.11 - 15/16 Experts: > > Here's a few important details of the Portland meeting being held August > 21 > - 25. > > 1. The hotel will release the block of rooms on Monday, Aug 7th. We > currently have half of the projected number of participants registered. > This > creates a problem for both Intel and the unregistered participants. The > delay of registrations means that late-registrants may not get a room > (there's few, if any, alternatives in this remote location) and Intel is > liable for unused rooms. To avoid a meeting fee (due to the liability), we > ask that everyone register as soon as possible. Registrations after Aug > 7th > will incur a late-registration fee of $300, charged by the hotel upon > check-in. You may download the registration form from this URL: > http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip > > If you cannot download the form or have difficulties with faxing it, > please > send mailto:valeriex.nester@intel.com. A signed form will still be needed > but this will help avoid a late-registratin fee. Be sure to indicate your > check-in and check-out dates, which Question you will attend and how many > guests you will have attend the Event Dinner on Wednesday. > > 2. Several people have asked for true Kosher food. The hotel can arrange > for > a special delivery of Kosher if the meals are prepaid. Lunches are around > $16 and dinners around $30. Please contact Janine Voudrie > [Janine.Voudrie(a)theresort.com, +1-503-622-2221] with your requests and > payment information. Orders will need to be received by August 14th. > > Greg Meyer > Intel Corporation > mailto:greg.w.meyer@intel.com > +1.503.264.9506 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: Request for APC number
by Sakae OKUBO 04 Aug '00

04 Aug '00

Dear Mr. Reddy, In response to your request, the following APC numbers have been allocated to your three contributions: APC-1900 >Contribution 1: H.246 Annex E.1 Interworking between H.225.0 and PLMN's >Mobile Application Parts APC-1901 >Contribution 2: H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 >PLMN Mobile Application Part APC-1902 >Contribution 3: H.323 Mobility services using IETF's Mobile IP and new >extended protocols I have registered the first two being from Editor (P Reddy) and the third from Intel. Best regards, Sakae OKUBO *********************************************************** 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 *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Important Portland Meeting Details & Late Fees
by Meyer, Greg W 04 Aug '00

04 Aug '00

Q.11 - 15/16 Experts: Here's a few important details of the Portland meeting being held August 21 - 25. 1. The hotel will release the block of rooms on Monday, Aug 7th. We currently have half of the projected number of participants registered. This creates a problem for both Intel and the unregistered participants. The delay of registrations means that late-registrants may not get a room (there's few, if any, alternatives in this remote location) and Intel is liable for unused rooms. To avoid a meeting fee (due to the liability), we ask that everyone register as soon as possible. Registrations after Aug 7th will incur a late-registration fee of $300, charged by the hotel upon check-in. You may download the registration form from this URL: http://standard.pictel.com/ftp/avc-site/0008_Por/PortlandInfoPack.zip If you cannot download the form or have difficulties with faxing it, please send mailto:valeriex.nester@intel.com. A signed form will still be needed but this will help avoid a late-registratin fee. Be sure to indicate your check-in and check-out dates, which Question you will attend and how many guests you will have attend the Event Dinner on Wednesday. 2. Several people have asked for true Kosher food. The hotel can arrange for a special delivery of Kosher if the meals are prepaid. Lunches are around $16 and dinners around $30. Please contact Janine Voudrie [Janine.Voudrie(a)theresort.com, +1-503-622-2221] with your requests and payment information. Orders will need to be received by August 14th. Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225-Annex G
by Archana Nehru 04 Aug '00

04 Aug '00

paul, I have been looking for some clarifications on H.225-Annex G and somehow my mails to the editor, Michael Fortinsky from vocalTech are not getting answered. Since you are the editor for H.323, I was just wondering if you have any idea about who to contact now for any queries relating to H.225-Annex G in such a situation. Is there anyone else out there that is responsible for H.225- Annex G ? Thanks Archana

1 0

[Robustness] 8/3 call
by Terry L Anderson 04 Aug '00

04 Aug '00

Aug 3 was our last Robustness call before Portland (I will be on vacation until the Portland meeting). Attending: Terry Anderson - Lucent Sasha Ruditsky - Radvision Archana Nehru - Trillium Issues: 1) this was last call before portland. 2) 9.3.1.2 may not be needed 3) note 1 in 9.3.1.5 is no longer needed. 4) After detecting a TCP failure, can we find a way to probe the original addr before establishing to backup. There are some failures esp on Shared Repository entities (e.g., port listener process fails but can be restore, though keepalive timer may expire) where we might recover and be able to reestablish to same entity. This permits more complete recovery, but TCP connection attempt times out too slowly to use. Can we probe with ping etc? 5) Parts of 9.3 should be moved to common in 8. 6) 10.3 note about race condition. We can replace the race condition handling by using the same logic used in H.245 channel establishment (end with numerically smaller h245addr drop its connection). This handle both mux and non-mux cases. 7) item #7 in 12 isn't clear how it differ in Method A and Method B. 8) H.323 8.6 mods in 13.1.2 are for both Method A and B but how do we handle this if H.323 is NOT changed. Can we override this in Annex without changing H.323 text here? 9) 8.6.1 addition is only for Method A and should move there. If it stays in Annex it needs to be merged with other text as there is duplication. 10) if entity A supports only Method A and entity B has shared repository, then it would be nice to have a specification that only B sends keepalive and only B detects failure. This allows recovery from some errors (due to data in shared repository) without moving to backup. Effects text in several places. 11) What was our plan for backup GKs? AltGK gives addr to RRQ and send new ARQs to but how handle DRQs for continuing calls? If part of endpoint fails and recovers do we need to allow that the endpoint's rasaddr may be different? It can reRRQ to give the new rasaddr but how indicate the use of new rasADDR for existing calls (IRQ, forced DRQ, etc). Do we need to supply backupRasAddr in RRQ or way to indicate in RRQ that it is takeing over all calls to a previous rasAddr? Implied by endpointId???? A new draft addressing some of these and with notes about the others was submitted as APC-1878 and uploaded. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

APC-1878
by Terry L Anderson 04 Aug '00

04 Aug '00

APC-1878 Annex R Draft has been uploaded to the avc-site/incoming directory. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Francois-Xavier Derome 03 Aug '00

03 Aug '00

roy, You're right, there is a new interface between the BE and the HLF, but it is in the "mobile domain", so I don't think it breaks anything. And we can have an HLF-HLF in a second step, but not today since we don't want to mandate anything new in the originationg domain. fx "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> on 02/08/2000 03:46:53 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: Francois-Xavier DEROME/FR/ALCATEL) Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs Hi, FX: I like your approach that you have stated here in the email. With respect to the draft APC.xxx that you have proposed, I have few questions: 1. At present in H.323, there are mechanisms in place how the communications need to be made between the GKs or between the BEs or between the GK-BE and BE-GK when the user remain in one GK (or GK-BE) can communicate for resolving the information with another user located within another GK (or BE/GK). That is, the communication is made via the GK (or GK/BE) to locate another GK (or GK/BE) where is use is residing (for resolving information or placing a call). 2. The base H.323 spec and H.225.0 Annex G spec clearly provide those mechanisms as stated in item 1. However, your contribution appears to suggest that a GK (or BE) will use the VLF and HLF to locate another GK (or BE) where the user resides (currently). My assumption is that there can be HLF-to-HLF communications by-passing the GK-to-GK (or GK/BE-BE/GK) communications for resolving the information. It has been mentioned in my earlier emails that HLF-to-HLF communications is not an extension of H.323 protocol. Therefore, it appears to me that your contribution does not follow the model that have been suggested in items 1 and 2 per H.323 and Annex G. Am I missing anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Francois-Xavier Derome [mailto:Francois-Xavier.Derome@ALCATEL.FR] Sent: Tuesday, August 01, 2000 5:44 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs I tried to follow your discussion on annex G. Can we split the problem in 2 parts : - the mobility management - the call control Concerning the mobility management, I think we can define the rules we want and there should be no restriction from the current annex G limitation. Concerning the call management, we MUST follow the current annex G and that's what I wanted to make clear in my APC. I think one solution could be for the BE in the mobile domain to put in the routeinfo field a sendAccessRequest to let him resolve the new location with the HLF fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: [H.323 Mobility:]
by Jaakko Sundquist 03 Aug '00

03 Aug '00

Hi Francois, The MDs are documents for the interim work between meetings concerning the H.323 Mobility issues. If you want to make a contribution to the Portland meeting, you have to get an APC-number from Mr. Okubo, but if you want to issue a non-official Mobility ad hoc group contribution before the Portland meeting, you can get an MD-number from me. So should I allocate an MD-number for you? -Jaakko > -----Original Message----- > From: EXT Francois-Xavier Derome > [mailto:Francois-Xavier.Derome@ALCATEL.FR] > Sent: 03. August 2000 12:53 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] > > > Hi jaakko, > I saw you always do md, is it what I should do instead of an apc ? > fx > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: [H.323 Mobility:]
by Francois-Xavier Derome 03 Aug '00

03 Aug '00

Hi jaakko, I saw you always do md, is it what I should do instead of an apc ? fx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0