- sg16-avd - lists.packetizer.com

H.323 Annex M
by Francois Audet 12 Jan '00

12 Jan '00

I have uploaded the current draft for H.323 Annex M (Tunnelling of signalling protocols - QSIG) in the incoming directory as d-H323M.doc. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

1 0

[Fwd: FW: I-D ACTION:draft-singh-sip-h323-00.txt,.ps]
by Edgar Martinez [1] 12 Jan '00

12 Jan '00

fyi -------- Original Message -------- Subject: FW: I-D ACTION:draft-singh-sip-h323-00.txt,.ps Date: Wed, 12 Jan 2000 11:37:28 -0600 From: Shore Melinda <Melinda.Shore(a)NOKIA.COM> Reply-To: Melinda.Shore(a)NOKIA.COM To: TIPHON(a)LIST.ETSI.FR For those who don't receive IETF announcements ... Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street "Software longa, Ithaca, NY 14850 hardware brevis" +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) melinda.shore(a)nokia.com -----Original Message----- From: EXT Internet-Drafts(a)ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, January 12, 2000 6:40 AM Subject: I-D ACTION:draft-singh-sip-h323-00.txt,.ps A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interworking Between SIP/SDP and H.323 Author(s) : K. Singh, H. Schulzrinne Filename : draft-singh-sip-h323-00.txt,.ps Pages : 46 Date : 11-Jan-00 This document describes the interworking between SIP and H.323, including the translation between H.245 and SDP. We list general requirements for such a translation and a solution which meets those requirements. We describe the call setup via message flows and pseudo code. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-singh-sip-h323-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-singh-sip-h323-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-singh-sip-h323-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

H.323 mobility: Final draft
by Gilles Delmas 11 Jan '00

11 Jan '00

Status Distribution January 12, 2000 05:54:37 Sent by EMAUO01 The message regarding "H.323 mobility: Final draft" sent on January 12, 2000 05:54:37 was sent by Status Recipient Type To Native Name ITU-SG16(a)MAILBAG.INTEL.COM Foreign Native Name ITU-SG16(a)MAILBAG.INTEL.COM/n/n/nSMTP Recipients Status Reporters Type From Name Domain LOTUS Native Name CN=Gilles Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS@EMEA1 Foreign Native Name CN=Gilles Delmas/OU=LIM/OU=RESEARCH/O=PHILIPS/nEMEA1/n/n Organization PHILIPS Org Unit 1 RESEARCH Org Unit 2 LIM Last Name Delmas First Name Gilles Status 769 Explanation Invalid recipient X.400 Status 769 Explanation Error delivering to SUR003M/M/SERVER/PHILIPS mail5/gillesdelmas.nsf; File truncated - file may have been damaged

1 0

[Fwd: H.323 mobility: Final draft]
by Edgar Martinez [1] 11 Jan '00

11 Jan '00

ooh!! the final draft is MTD-03d.zip not MTD-03b.zip -------- Original Message -------- Subject: H.323 mobility: Final draft Date: Tue, 11 Jan 2000 22:48:58 -0500 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> Dear H.323 mobile ad-hoc group, I have down loaded MTD-03b.zip the H.323 mobile ad-hoc join contribution for Geneva and SGD-01-18-2000.zip for the US SGD meeting on Jan. 18, 2000 meeting in Washington D.C., for US approval of our combined contributions to Geneva. You may pick the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… Thank you all for all your help, see you in Geneva. Best Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 mobility: Final draft
by Edgar Martinez [1] 11 Jan '00

11 Jan '00

Dear H.323 mobile ad-hoc group, I have down loaded MTD-03b.zip the H.323 mobile ad-hoc join contribution for Geneva and SGD-01-18-2000.zip for the US SGD meeting on Jan. 18, 2000 meeting in Washington D.C., for US approval of our combined contributions to Geneva. You may pick the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… Thank you all for all your help, see in Geneva. Best Regards, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

I'm out of the office (auto reply)
by Francois-Xavier Kowalski 11 Jan '00

11 Jan '00

Hello, I am absent from January 10 to January 24. During this time, I will not be able to access my e-mail. If necessary, please contact: Pierre Lebret - Hewlett-Packard Telecom Infrastructure Division phone: +33 (0) 4 76 14 57 21 e-mail: pierre_lebret(a)grenoble.hp.com Thank you. Francois-Xavier Kowalski.

1 0

joint meeting with SG11
by /Q11, Q12, Q13 10 Jan '00

10 Jan '00

I have heard that we will have a joint meeting with SG11 the 14th - 18th feb week in Geneva.. Is this somehow true ??? Is their something planned ? If yes could someone tell me what is the agenda or items to be discussed?? Thank you Ameneh Zahir Alcatel

3 2

Re: H.323 mobility: last call
by Jaakko Sundquist 10 Jan '00

10 Jan '00

Hi all, Unfortunately I can not attend the telephony conference this evening (yep, evening for us), but at least Senthil will be there representing Nokia. There doesn't seem to be any major issues that we would like to change in the draft Annex H (MTD-03c) at the moment, so if no major changes are introduced to it, I we are willing to be co-contributors of the contribution (that the draft will hopefully be) for the Geneva meeting. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. ------------------------------------------------------- -----Original Message----- From: EXT Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Monday, January 10, 2000 3:18 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 mobility: last call Hi, Everyone: Ed Martinez has provided a good input with respect to the US SG-D meeting that the meeting will be held on January 18 (not the date what I expected before). Let us talk about the document MTD-3c as proposed. In addition, we can discuss more if we have time in today's conference call. Best Regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Sunday, January 09, 2000 2:23 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 mobility: last call > Importance: High > > Dear H.323 Mobilty group, > > This maybe the last meeting with the U.S.A group. The > Study Group D meeting is set for Jan 18, 2000. Where > we need to have an agreed contribution from the mobile Ad-hoc > group so we can present it in the full Sg16 meeting in Geneva. > > I propose we go over MTD-3c which already includes > the Nokia contribution. Then go over the remaining contributions > and spend no more then 10 minutes on each. Whatever can be added > and agreed on will be included in the final MTD-3d. If we can not > agreed on adding anything after the MTD-3c review which will include > Nokia's updates, I propose to take MTD-3c as it is, to study group D > in washington d.c. for the Jan 18, 2000 meeting. > > What will be presented in Study group D is the H.323 mobilty document > outline and the contents we have agreed so far. > > --- > Conference call will be held as follows: > > Date: January 10, 2000 > Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) > Reservation # 13928768 > Number port reserved: 20 Ports > Conference Call Bridge call in number: +1 (415)-904-8877 > Passcode: 8813575 > > 1. Call to Order & Opening Remarks > 2. Attendance Registration > 4. Agenda Review and Approval: MTD-01f > 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f > 6. Review Carry over contributions and review sequence proposal, (see > table 1 of MTD-01f) > 7. Discuss next conference call meetings > 8. Review Assignments > 9. Review Workplan > 10. Open Discussion > 11. Adjourn > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 mobility: last call
by Frank Derks 10 Jan '00

10 Jan '00

Is there a location where I can download the MTD-3c document? The two links provided by Edgar do not work for me (ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… ). Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- rrroy@ATT.COM@SMTP@MAILBAG.INTEL.COM on 10/01/2000 14:33:48 Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: H.323 mobility: last call Classification: Restricted Hi, Everyone: Ed Martinez has provided a good input with respect to the US SG-D meeting that the meeting will be held on January 18 (not the date what I expected before). Let us talk about the document MTD-3c as proposed. In addition, we can discuss more if we have time in today's conference call. Best Regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Sunday, January 09, 2000 2:23 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 mobility: last call > Importance: High > > Dear H.323 Mobilty group, > > This maybe the last meeting with the U.S.A group. The > Study Group D meeting is set for Jan 18, 2000. Where > we need to have an agreed contribution from the mobile Ad-hoc > group so we can present it in the full Sg16 meeting in Geneva. > > I propose we go over MTD-3c which already includes > the Nokia contribution. Then go over the remaining contributions > and spend no more then 10 minutes on each. Whatever can be added > and agreed on will be included in the final MTD-3d. If we can not > agreed on adding anything after the MTD-3c review which will include > Nokia's updates, I propose to take MTD-3c as it is, to study group D > in washington d.c. for the Jan 18, 2000 meeting. > > What will be presented in Study group D is the H.323 mobilty document > outline and the contents we have agreed so far. > > --- > Conference call will be held as follows: > > Date: January 10, 2000 > Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) > Reservation # 13928768 > Number port reserved: 20 Ports > Conference Call Bridge call in number: +1 (415)-904-8877 > Passcode: 8813575 > > 1. Call to Order & Opening Remarks > 2. Attendance Registration > 4. Agenda Review and Approval: MTD-01f > 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f > 6. Review Carry over contributions and review sequence proposal, (see > table 1 of MTD-01f) > 7. Discuss next conference call meetings > 8. Review Assignments > 9. Review Workplan > 10. Open Discussion > 11. Adjourn > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 mobility: last call
by Roy, Radhika R, ALARC 10 Jan '00

10 Jan '00

Hi, Everyone: Ed Martinez has provided a good input with respect to the US SG-D meeting that the meeting will be held on January 18 (not the date what I expected before). Let us talk about the document MTD-3c as proposed. In addition, we can discuss more if we have time in today's conference call. Best Regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Sunday, January 09, 2000 2:23 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 mobility: last call > Importance: High > > Dear H.323 Mobilty group, > > This maybe the last meeting with the U.S.A group. The > Study Group D meeting is set for Jan 18, 2000. Where > we need to have an agreed contribution from the mobile Ad-hoc > group so we can present it in the full Sg16 meeting in Geneva. > > I propose we go over MTD-3c which already includes > the Nokia contribution. Then go over the remaining contributions > and spend no more then 10 minutes on each. Whatever can be added > and agreed on will be included in the final MTD-3d. If we can not > agreed on adding anything after the MTD-3c review which will include > Nokia's updates, I propose to take MTD-3c as it is, to study group D > in washington d.c. for the Jan 18, 2000 meeting. > > What will be presented in Study group D is the H.323 mobilty document > outline and the contents we have agreed so far. > > --- > Conference call will be held as follows: > > Date: January 10, 2000 > Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) > Reservation # 13928768 > Number port reserved: 20 Ports > Conference Call Bridge call in number: +1 (415)-904-8877 > Passcode: 8813575 > > 1. Call to Order & Opening Remarks > 2. Attendance Registration > 4. Agenda Review and Approval: MTD-01f > 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f > 6. Review Carry over contributions and review sequence proposal, (see > table 1 of MTD-01f) > 7. Discuss next conference call meetings > 8. Review Assignments > 9. Review Workplan > 10. Open Discussion > 11. Adjourn > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

[Fwd: H.323 mobility: last call]
by Edgar Martinez [1] 09 Jan '00

09 Jan '00

You can pick the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… -------- Original Message -------- Subject: H.323 mobility: last call Date: Sun, 09 Jan 2000 14:22:51 -0500 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: "H.323 Mobility" <ITU-SG16(a)mailbag.cps.intel.com> Dear H.323 Mobilty group, This maybe the last meeting with the U.S.A group. The Study Group D meeting is set for Jan 18, 2000. Where we need to have an agreed contribution from the mobile Ad-hoc group so we can present it in the full Sg16 meeting in Geneva. I propose we go over MTD-3c which already includes the Nokia contribution. Then go over the remaining contributions and spend no more then 10 minutes on each. Whatever can be added and agreed on will be included in the final MTD-3d. If we can not agreed on adding anything after the MTD-3c review which will include Nokia's updates, I propose to take MTD-3c as it is, to study group D in washington d.c. for the Jan 18, 2000 meeting. What will be presented in Study group D is the H.323 mobilty document outline and the contents we have agreed so far. --- Conference call will be held as follows: Date: January 10, 2000 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13928768 Number port reserved: 20 Ports Conference Call Bridge call in number: +1 (415)-904-8877 Passcode: 8813575 1. Call to Order & Opening Remarks 2. Attendance Registration 4. Agenda Review and Approval: MTD-01f 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f 6. Review Carry over contributions and review sequence proposal, (see table 1 of MTD-01f) 7. Discuss next conference call meetings 8. Review Assignments 9. Review Workplan 10. Open Discussion 11. Adjourn -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 mobility: last call
by Edgar Martinez [1] 09 Jan '00

09 Jan '00

Dear H.323 Mobilty group, This maybe the last meeting with the U.S.A group. The Study Group D meeting is set for Jan 18, 2000. Where we need to have an agreed contribution from the mobile Ad-hoc group so we can present it in the full Sg16 meeting in Geneva. I propose we go over MTD-3c which already includes the Nokia contribution. Then go over the remaining contributions and spend no more then 10 minutes on each. Whatever can be added and agreed on will be included in the final MTD-3d. If we can not agreed on adding anything after the MTD-3c review which will include Nokia's updates, I propose to take MTD-3c as it is, to study group D in washington d.c. for the Jan 18, 2000 meeting. What will be presented in Study group D is the H.323 mobilty document outline and the contents we have agreed so far. --- Conference call will be held as follows: Date: January 10, 2000 Time: 8:00 AM to 10:00 AM (Pacific Standard Time (PST)) Reservation # 13928768 Number port reserved: 20 Ports Conference Call Bridge call in number: +1 (415)-904-8877 Passcode: 8813575 1. Call to Order & Opening Remarks 2. Attendance Registration 4. Agenda Review and Approval: MTD-01f 5. Review H.323 Mobility Ad Hoc Meeting report: MTD-02f 6. Review Carry over contributions and review sequence proposal, (see table 1 of MTD-01f) 7. Discuss next conference call meetings 8. Review Assignments 9. Review Workplan 10. Open Discussion 11. Adjourn -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.225 Annex G and UsageIndication
by Michael Fortinsky 09 Jan '00

09 Jan '00

I have a question relating to H.225 Annex G, section 1.8.2.28 (Usage Indication). The standard says the following about the SourceAddress field: "SourceAddress E.164 or e-mail address of the caller party. In case of E.164 this designates the ANI/CLI." i.e., if the SourceAddress is an E.164 number, this refers to the ANI/CLI of the caller. Is this always true? Is AnnexG unnecessarily limiting the semantics of the SourceAddress field? I can think of a case when the AnnexG definition might be a problem. Think of a system where each subscriber in the system is assigned a globally unique "internet telephone number". In this case, the caller's identifier will look like an E.164 number, but it will not be the ANI/CLI. A border element or clearing house that assumes the E.164 is an ANI/CLI will be making a mistake. Does anyone have any ideas how this scenario can be handled within the context of AnnexG? Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

minor problems in H.225 Annex G
by Michael Fortinsky 06 Jan '00

06 Jan '00

Here are a few problems I've found in H.225 Annex G. They are problems of an "editorial" nature, but should probably be fixed in the near term (Geneva?). (1) Section 1.7.1 - The end of the first paragraph states the following: " (Note that since " * " is a meaningful character, the template actually includes a Boolean flag to indicate whether the address is specific or not. These examples use " * " to indicate a wild card, but the actual representation in the template is through the Boolean flag.) " In the latest version of the Annex, there is no longer a boolean flag in the template. Each pattern in a template explicitly indicates whether it is a specific or wildcard pattern. I suggest to change the wording to: " (Note that templates do not use the " * " character to indicate whether an address is specific or not because the " * " character can have other meanings - e.g., within an AliasAddress. Instead, the template explicitly specifies whether an address is a specific or a wildcard address. For illustrative purposes, the examples that follow use " * " to indicate a wildcard address.) " (2) Section 1.7.1.2 - The first paragraph states: "A border element may request the statically configured templates from another border element." I think there is no reason to differentiate between templates that were configured statically and those received dynamically. I suggest the wording: "A border element may request templates from another border element." (3) Section 1.8.2.1 The third field, gatekeeperID, should be called elementIdentifier, for the following reasons: - a gatekeeper does not own a descriptor - a border element does - to be consistent with other messages (which use the elementIdentifier to represent the id of the relevant border element) The Field and Description for this field should be changed to: Field Description ================================= elementIdentifier This is a text identifier that indicates the owner of the descriptor (i.e., the border element that created this message The ASN.1 for Descriptor should also be changed from: Descriptor ::= SEQUENCE { descriptorInfo DescriptorInfo, templates SEQUENCE OF AddressTemplate, gatekeeperID GatekeeperIdentifier OPTIONAL, ... } to: Descriptor ::= SEQUENCE { descriptorInfo DescriptorInfo, templates SEQUENCE OF AddressTemplate, elementIdentifier ElementIdentifier OPTIONAL, ... } (4) Section 1.8.2.3.3 - There is a typo in the Description of the transportQoS field. It currently states: transportQoS Indicates where the responsibility lies for resource reservation for the all made through this contact. I suggest: transportQoS Indicates where the responsibility lies for resource reservation for a call made through this contact. (5) Section 1.8.2.5 - There is a typo - the term SecurityCapability is misspelled. (6) Section 2 (ASN.1 definitions) - the specification of serviceID is not correct. It reads: serviceID ::= GloballyUniqueID The "s" in serviceID should be capitalized. The correct line is: ServiceID ::= GloballyUniqueID This is actually a more serious problem, because it will cause ASN.1 compilation problems. Michael Fortinsky ----------------------------------------------------------------- Program Manager, Servers Group R&D, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Re: Closing Q.931 TCP connection..
by Callaghan, Robert 06 Jan '00

06 Jan '00

Boaz, This is a missing point in this discussion. The proposal is to close the Call Signaling channel because it is anticipated that there is no additional use for the channel. If this anticipation is wrong, a procedure is required to reopen the call signaling channel and to resynchronize all the state information. What is the proposed procedure for reopening this channel? Please do not state that your application does not use H.450 or any other subsequent use of the call signaling channel. Even though your gatekeeper does not use H.450, my endpoint does and interworking is required. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Boaz Michaely [mailto:Boaz_Michaely@VOCALTEC.COM] Sent: Wednesday, January 05, 2000 4:47 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Closing Q.931 TCP connection.. Hi Chris, Glad I caught your interest ... Let me clarify some points which seem to have been misunderstood: (I'll try shorthand this time :-) 1. The case is NOT made for the GK not being the point for SETUP to call. Quite the reverse: I propose that the GK *is* the single point to call, and that it executes load balancing logic to distribute the H.245 negotiations elsewhere. 2. Varying the address given in AnnexG defetes no 1. 3. H.450.2 has nothing to do with it as the call is NOT being redirected. It is merely being decomposed. 4. You are NOT required to remove the call signalling at all. I'm afraid my point has been completely missed : I call for ALLOWING the close of the "Q.931" TCP signalling channel, while maintaining only the MEDIA CONTROL (h.245) channel open. 5. I too suspect that this scenario "just works", which is why I find it attractive to continue to allow closing of the Q.931 channel mid-call, WITHOUT killing the call . (again - this is perfectly legal today). We may need to update the standard, though, in order to solve the problems that Paul identified ! Thanks for your thoughts, Boaz -------- On 04/01/2000 06:27 PM GMT Chris Wayman Purvis <cwp(a)ISDN-COMMS.CO.UK> wrote: Boaz, The beast you describe is very strange and, as Paul says, interesting. Permit me to copy a para from your mail, in order to take issue with it! >> Once a SETUP message comes in, the GK replies with an H.245 address of the >> applicable MG. Note that the GK has to be the point of call for SETUP, >> since it may use the information in the SETUP message for finding the >> applicable MG (i.e. using CLI and/or DNIS), as well as it performs load >> balancing on the MGs. I'm not convinced the case is made here for the GK not being the point for SETUP to call. As you postulate the use of "SendSetup" Annex G messages, load balancing can be achieved adequately by varying the address given there. I'm hazy about how much information Annex G gives you as to the source of a call, but would hope that the sort of information that will be useful here (such as country of origin of the call) would be available (maybe an Annex G expert can help here?)? Even given the GK as the destination for the original setup message, H.450.2(? I think it's 2!) would allow the call to be redirected elsewhere once the GK has looked at that message. What I'm saying in general is that I'd hope to be able to achieve your application without requiring the removal of the call signalling channel, and I'm sure there are at least two ways of doing it, depending on precisely what you require, without any new standards needing to be written. In most cases I'm agnostic about Paul's point of a gatekeeper routing call control (H.225.0) but not connection control (H.245). In my view everything just works. BUT I believe that in order for everything to "just work" the assumption has to be there that the call control channel doesn't die mid-call. Regards, Chris "Paul E. Jones" wrote: > > Boaz, > > I do consistently argue against closing the call signaling channel. But > there are good reasons for this: > 1) Many devices out there clear the call when the channel is closed (yes, > this is wrong, but it's a fact of life :-) > 2) Closing the call signaling channel prohibits (or complicates) the use of > supplementary services and other in-band signaling. > > The text to which Chris Purvis refers is section 6.1. Here is an extraction > of that text: > ``For the gatekeeper mediated call signalling case (see Figure 8/H.323), the > terminals shall keep the reliable port active throughout the call. However, > the gatekeeper may choose to close this signalling channel, but should keep > the channel open for calls that involve gateways. This will allow the > end-to-end transmission of Q.931 information elements such as display > information.'' > > What you propose below is interesting and may yield a more scalable > solution. Perhaps this should be explored. I might note, though, that at > the moment, such a configuration is "undefined". According to H.323, > routing the call signaling through a Gatekeeper, but not the H.245, is "for > further study". It might be interesting to read contributions from you that > might open this area for study. > > Best Regards, > Paul > > ----- Original Message ----- > From: "Boaz Michaely" <Boaz_Michaely(a)vocaltec.com> > To: "Paul E. Jones" <paul.jones(a)ties.itu.int> > Cc: <h323implementors(a)imtc.org>; <itu-sg16(a)mailbag.cps.intel.com> > Sent: Thursday, December 30, 1999 7:40 PM > Subject: Re: Closing Q.931 TCP connection.. > > > Happy new Y2K ! > > Your consistent argueing against closing the Q.931 sig. channel, is > > appreciable, and I share your concern for many service scenarios. (I guess > > we'll talk more about this in February, which is why the ITU-SG16 list is > > copied) > > However, in the following scenario, it seems highly desireable to be able > > to close the sig. channel: > > (if this has been described before, please forgive my ignorance) > > > > Think of a scaleable IVR server farm which is implemented using multiple > > MG's, each capable of H.245, RTP/RTCP, and a very simple control protocol > > (H.248 ?). A single GRC GK, which is also an AnnexG Border Element is used > > as the single entry into this port-dense system. > > This GK may be addressed using LRQ from another domain (e.g. that of an > > ITSP). In addition, it publishes its own address using "SendSetup" type of > > addressing in the AnnexG templates that it publishes. > > > > Once a SETUP message comes in, the GK replies with an H.245 address of the > > applicable MG. Note that the GK has to be the point of call for SETUP, > > since it may use the information in the SETUP message for finding the > > applicable MG > > (i.e. using CLI and/or DNIS), as well as it performs load balancing on the > > MGs. > > Now the audio session is connected and the call takes place, while the MG > > handles the DTMFs and all the logic. > > Let's assume that there are no changes in the call routing from this point > > on (which is typically the case in, say, automatic banking systems etc.) > > GK intervention is not required any more until the call is done. > > > > It would be nice if the GK could get rid of the dangling Q.931 TCP > > connection, while the RTP call continues until it is disconnected by the > > human caller. If I understand correctly, this is a perfectly legitimate > > behaviour using the existing standard. (I trust this is true for all > > versions ?) > > > > Assuming this scenario is valid (have I overlooked anything ?) can we find > > a way to continue to support it while reducing the mess for other services > > ? > > Reinitiating the sig. channel in some way may not be a bad idea ? > > > > Finally, I must admit I do not understand Chris's comment about making > sure > > the other party is not a GW. > > Why is that so? > > > > > > Boaz Michaely > > VocalTec Communications Ltd. > > +972 (9) 970-7869 > > email: boaz(a)vocaltec.com > > http://people.itu.int/~michaely > > > > > > > > > > > > > > "Paul E. Jones" <paul.jones(a)ties.itu.int> on 02/01/2000 12:04:50 AM > > > > Please respond to "Paul E. Jones" <paul.jones(a)ties.itu.int> > > > > To: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk>, "Satya T" > > <satyat(a)MIEL.MOT.COM> > > cc: h323implementors(a)imtc.org (bcc: Boaz Michaely) > > Subject: Re: Closing Q.931 TCP connection.. > > > > > > > > > > Folks, > > > > I would like to second Chris' comments. It really is a very bad idea to > > close the call signaling channel. This might have been important prior to > > H.245 tunneling and Fast Connect, but in my opinion, this just isn't > > necessary any longer. > > > > My chief complaint is that once the channel is closed, there's no > guarantee > > one can re-open it. This is especially true on the receiving end-- the > > called endpoint may not know the call signaling address to which to try to > > re-establish a socket connection, and it cannot assume 1720. Reverse call > > setup may not even be possible, given some network arrangements (including > > the usage of devices to traverse firewalls). > > > > There are several reasons to keep the channel open, too. This gives the > > endpoint the ability to perform supplementary services. If the channel is > > closed, the endpoints lose that functionality-- unless we can guarantee a > > way of re-establishing that channel. > > > > So, my advise to all implementers: never, never close the call signaling > > channel. > > > > Paul > > > > ----- Original Message ----- > > From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> > > To: "Satya T" <satyat(a)MIEL.MOT.COM> > > Cc: <h323implementors(a)imtc.org> > > Sent: Tuesday, December 21, 1999 8:52 AM > > Subject: Re: Closing Q.931 TCP connection.. > > > > > > > Satya, > > > > > > This is the subject of much current discussion, but the group within ITU > > SG16 > > > discussing robustness. Currently: > > > ReleaseComplete closes the call. > > > Closing the Q.931 TCP connection without ReleaseComplete does not close > > the > > > call if there is a separate active H.245 connection. > > > However, consideration is being given to the possibility of changing > this > > rule, > > > if no implementations can be found that deliberately close the Q.931 TCP > > > connection during a call. > > > > > > I strongly advise against deliberately closing the Q.931 TCP connection > > without > > > terminating the call, but as things currently stand > > > a) you are permitted do so as long as there is no gateway involved in > the > > call > > > (which you may or may not be able to know!!!) > > > b) you should cope with other parties in the call doing this (unless you > > or > > > they are a gateway!!!!!). > > > > > > Regards, > > > Chris > > > > > > Satya T wrote: > > > > > > > > Hi all, > > > > There's a gatekeeper routed call, > > > > and if the GK closes down the Q931 TCP connection, > > > > does it mean the call is closed? Consider the following cases : > > > > > > > > 1. When GK sends RELEASE complete before breaking > > > > down the TCP > > > > 2. When GK does NOT send RELEASE complete before > > > > breaking down TCP > > > > > > > > H.245 connection is established & ON directly between the EPs in > > > > both cases when the Q931 TCP is broken down. > > > > > > > > Is it considered closed in both the scenarios? or only in the former? > > > > > > > > regards > > > > Satya T > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > > > > -------------------------------------------------------------------------- > > -------------------------------------------------------------------------- > - > > ------------------------------ > > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > > subscribe or unsubscribe from this list > > ------------------------------ > > -------------------------------------------------------------------------- > - > > > > > > > > > > > > > > --------------------------------------------------------------------------- > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > --------------------------------------------------------------------------- -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

2 1

MTD-107
by Nicolas Tran 06 Jan '00

06 Jan '00

Dear Mr Martinez, Happy new Y2K !! Please, could you tell me if the MTD-107b is approved after the last discussion?. Do you add/modify the suggested texts in the baseline document?. Best regards, Nicolas TRAN.

1 0

[Robustness] conference call today Jan 6 -- final reminder
by Maureen Stillman 06 Jan '00

06 Jan '00

The minutes from the last robustness telecon held on December 14, 1999 are attached. The next conference call for robustness, arranged by Nokia, is scheduled for Thursday, January 6th at 11:00 AM EST USA. Agenda for the teleconference: Discuss draft submission to SG-16 Geneva meeting written by Radvision incorporating discussions from the last several robustness teleconferences. The goal is to submit this input to the meeting by the deadline of January 27, 2000. Radvision has posted this draft to the mailing list yestderday prior to the teleconference for our review. I have attached Radvision's draft to this message. Conference call number: 613-688-2795 The access code 5767#. You must enter the pound sign after the access code. -- maureen <<Robustness.zip>> Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

[Robustness] Re: Unregistered Calls
by Chris Wayman Purvis 06 Jan '00

06 Jan '00

Robustness people, This is something that's been being discussed on the IMTC's implementors reflector (no doubt most of you follow that anyway). I'd suggest that it ought to be within your terms of reference! I attach the earlier mail to which I'm referring. Raghu, Amit et al, History regularly comes to bite us here, and I probably didn't help by not explaining the starting points to my thinking! So here we are: 1. Your reference to 7.2.2 of whichever standard it is. I agree absolutely. Where possible. However... If an endpoint fails to find a gatekeeper during gatekeeper discovery, it is permitted to assume that there is no gatekeeper around, and that it may therefore make calls without using a gatekeeper. It might be considered "polite", however, for an endpoint carrying on this way to periodically check up to see if there ARE any gatekeepers around. At least one well known H.323 stack acts in this way if asked to handle RAS for its application. The question is, what should it do if it should find a gatekeeper at this later stage? 2. The obvious thing to do here is to drop any calls immediately, and remake them when we've registered with a gatekeeper, if and only if registration is successful. However it is surely desirable for the user to know nothing of what's going on (if possible - ie ONLY if registration is successful). Delays of a few seconds mid-call, and ringing phones spoil the user's experience. So either there should be some attempt to carry the call on uninterrupted or the call should just be dropped. 3. With all the moves in the ITU towards robustness, I really think it's up to that group to specify what heppens here. However, given that their terms of reference certainly DO include keeping the call up somehow or other in the event of gatekeeper failure (which, depending on what they specify, may result in a period in which the endpoint is in a call but not registered) calls continue uniterrupted, I'd suggest that this should be the aim here. 4. However a gatekeeper has the right to know about any calls its endpoints are participating in. The only way I could see to achieve this is via ARQ for an existing call, although again the robustness group may have some ideas! Regards, Chris Amit sahai wrote: > > Hi Raghu, > I was also thinking that this is the only viable solution . Ep > should close all > calls and start again . > What do you think Chris ? > > regards > Amit Sahai > Convergence Technology Group, > Silicon Automation Systems. > > raghu.nambiath(a)wipro.com wrote: > > > Hi Amit, > > > > I think there are other issues involved if ARQ needs to be sent for an > > ongoing call by the endpoint after registering with the Gatekeeper. This is > > the case if the Gatekeeper had decide to route the call. In this case what > > will happen to the current call status. Only way will be the endpoint close > > the existing call and restart the same.. > > > > Raghu > > > > > -----Original Message----- > > > From: owner-h323implementors(a)imtc.org > > > [mailto:owner-h323implementors@imtc.org]On Behalf Of Amit sahai > > > Sent: Thursday, January 06, 2000 1:12 PM > > > To: cwp(a)isdn-comms.co.uk; raghun(a)wipinfo.soft.net; > > > h323implementors(a)imtc.org > > > Subject: Re:Unregistered Calls > > > > > > > > > Hi Raghu, > > > I think the standard has apparently laid outlines for > > > such a > > > scenario. > > > I think it assumes that when endpoint is registered with a GK , for > > > all calls it > > > will > > > take permission from the GK . The underlying assumption is that no calls > > > were going > > > on > > > beforehand . > > > Ref. 7.2.2 Endpoint Registration > > > " Registration shall ocuur before any calls are attempted ......" > > > What do you think about this line ? > > > So this clearly is a scenario , not covered by the standard. > > > The solution which Chris has offered seems to be a logical thing. But > > > yet it is an > > > improvisation. I found no mention of such a case in the standards. > > > What I find strange is that ep is asking for ARQ for a call which is > > > already going > > > on ! > > > Consider this scenario: > > > Assume a case where a call was going on before registering with the > > > GK. > > > > > > As soon the endpoint registers with the GK , the ep asks GK for > > > Admission for > > > this calland GK grants it telling to route the Call Signalling through > > > GK ( The GK > > > has no knowledge of the call going on !) > > > Now ep is already engaged in a call and assumes permission has been > > > granted . > > > It does not follow Call Signalling procedures , since it does not need > > > to . > > > The GK does not know the call is going on while the endpoint thinks GK > > > has granted > > > permission . > > > > > > Don't we foresee problems with this situation ? Any comments .... > > > > > > > > > regards > > > Amit Sahai > > > Convergence Technology Group, > > > Silicon Automation Systems , > > > Bangalore. > > > > > > ------------------------------------------------------------------ > > > --------- > > > ------------------------------ > > > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > > > subscribe or unsubscribe from this list > > > ------------------------------ > > > ------------------------------------------------------------------ > > > --------- > > > -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

Re: Closing Q.931 TCP connection..
by Boaz Michaely 06 Jan '00

06 Jan '00

Hi Chris, Glad I caught your interest ... Let me clarify some points which seem to have been misunderstood: (I'll try shorthand this time :-) 1. The case is NOT made for the GK not being the point for SETUP to call. Quite the reverse: I propose that the GK *is* the single point to call, and that it executes load balancing logic to distribute the H.245 negotiations elsewhere. 2. Varying the address given in AnnexG defetes no 1. 3. H.450.2 has nothing to do with it as the call is NOT being redirected. It is merely being decomposed. 4. You are NOT required to remove the call signalling at all. I'm afraid my point has been completely missed : I call for ALLOWING the close of the "Q.931" TCP signalling channel, while maintaining only the MEDIA CONTROL (h.245) channel open. 5. I too suspect that this scenario "just works", which is why I find it attractive to continue to allow closing of the Q.931 channel mid-call, WITHOUT killing the call . (again - this is perfectly legal today). We may need to update the standard, though, in order to solve the problems that Paul identified ! Thanks for your thoughts, Boaz -------- On 04/01/2000 06:27 PM GMT Chris Wayman Purvis <cwp(a)ISDN-COMMS.CO.UK> wrote: Boaz, The beast you describe is very strange and, as Paul says, interesting. Permit me to copy a para from your mail, in order to take issue with it! >> Once a SETUP message comes in, the GK replies with an H.245 address of the >> applicable MG. Note that the GK has to be the point of call for SETUP, >> since it may use the information in the SETUP message for finding the >> applicable MG (i.e. using CLI and/or DNIS), as well as it performs load >> balancing on the MGs. I'm not convinced the case is made here for the GK not being the point for SETUP to call. As you postulate the use of "SendSetup" Annex G messages, load balancing can be achieved adequately by varying the address given there. I'm hazy about how much information Annex G gives you as to the source of a call, but would hope that the sort of information that will be useful here (such as country of origin of the call) would be available (maybe an Annex G expert can help here?)? Even given the GK as the destination for the original setup message, H.450.2(? I think it's 2!) would allow the call to be redirected elsewhere once the GK has looked at that message. What I'm saying in general is that I'd hope to be able to achieve your application without requiring the removal of the call signalling channel, and I'm sure there are at least two ways of doing it, depending on precisely what you require, without any new standards needing to be written. In most cases I'm agnostic about Paul's point of a gatekeeper routing call control (H.225.0) but not connection control (H.245). In my view everything just works. BUT I believe that in order for everything to "just work" the assumption has to be there that the call control channel doesn't die mid-call. Regards, Chris "Paul E. Jones" wrote: > > Boaz, > > I do consistently argue against closing the call signaling channel. But > there are good reasons for this: > 1) Many devices out there clear the call when the channel is closed (yes, > this is wrong, but it's a fact of life :-) > 2) Closing the call signaling channel prohibits (or complicates) the use of > supplementary services and other in-band signaling. > > The text to which Chris Purvis refers is section 6.1. Here is an extraction > of that text: > ``For the gatekeeper mediated call signalling case (see Figure 8/H.323), the > terminals shall keep the reliable port active throughout the call. However, > the gatekeeper may choose to close this signalling channel, but should keep > the channel open for calls that involve gateways. This will allow the > end-to-end transmission of Q.931 information elements such as display > information.'' > > What you propose below is interesting and may yield a more scalable > solution. Perhaps this should be explored. I might note, though, that at > the moment, such a configuration is "undefined". According to H.323, > routing the call signaling through a Gatekeeper, but not the H.245, is "for > further study". It might be interesting to read contributions from you that > might open this area for study. > > Best Regards, > Paul > > ----- Original Message ----- > From: "Boaz Michaely" <Boaz_Michaely(a)vocaltec.com> > To: "Paul E. Jones" <paul.jones(a)ties.itu.int> > Cc: <h323implementors(a)imtc.org>; <itu-sg16(a)mailbag.cps.intel.com> > Sent: Thursday, December 30, 1999 7:40 PM > Subject: Re: Closing Q.931 TCP connection.. > > > Happy new Y2K ! > > Your consistent argueing against closing the Q.931 sig. channel, is > > appreciable, and I share your concern for many service scenarios. (I guess > > we'll talk more about this in February, which is why the ITU-SG16 list is > > copied) > > However, in the following scenario, it seems highly desireable to be able > > to close the sig. channel: > > (if this has been described before, please forgive my ignorance) > > > > Think of a scaleable IVR server farm which is implemented using multiple > > MG's, each capable of H.245, RTP/RTCP, and a very simple control protocol > > (H.248 ?). A single GRC GK, which is also an AnnexG Border Element is used > > as the single entry into this port-dense system. > > This GK may be addressed using LRQ from another domain (e.g. that of an > > ITSP). In addition, it publishes its own address using "SendSetup" type of > > addressing in the AnnexG templates that it publishes. > > > > Once a SETUP message comes in, the GK replies with an H.245 address of the > > applicable MG. Note that the GK has to be the point of call for SETUP, > > since it may use the information in the SETUP message for finding the > > applicable MG > > (i.e. using CLI and/or DNIS), as well as it performs load balancing on the > > MGs. > > Now the audio session is connected and the call takes place, while the MG > > handles the DTMFs and all the logic. > > Let's assume that there are no changes in the call routing from this point > > on (which is typically the case in, say, automatic banking systems etc.) > > GK intervention is not required any more until the call is done. > > > > It would be nice if the GK could get rid of the dangling Q.931 TCP > > connection, while the RTP call continues until it is disconnected by the > > human caller. If I understand correctly, this is a perfectly legitimate > > behaviour using the existing standard. (I trust this is true for all > > versions ?) > > > > Assuming this scenario is valid (have I overlooked anything ?) can we find > > a way to continue to support it while reducing the mess for other services > > ? > > Reinitiating the sig. channel in some way may not be a bad idea ? > > > > Finally, I must admit I do not understand Chris's comment about making > sure > > the other party is not a GW. > > Why is that so? > > > > > > Boaz Michaely > > VocalTec Communications Ltd. > > +972 (9) 970-7869 > > email: boaz(a)vocaltec.com > > http://people.itu.int/~michaely > > > > > > > > > > > > > > "Paul E. Jones" <paul.jones(a)ties.itu.int> on 02/01/2000 12:04:50 AM > > > > Please respond to "Paul E. Jones" <paul.jones(a)ties.itu.int> > > > > To: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk>, "Satya T" > > <satyat(a)MIEL.MOT.COM> > > cc: h323implementors(a)imtc.org (bcc: Boaz Michaely) > > Subject: Re: Closing Q.931 TCP connection.. > > > > > > > > > > Folks, > > > > I would like to second Chris' comments. It really is a very bad idea to > > close the call signaling channel. This might have been important prior to > > H.245 tunneling and Fast Connect, but in my opinion, this just isn't > > necessary any longer. > > > > My chief complaint is that once the channel is closed, there's no > guarantee > > one can re-open it. This is especially true on the receiving end-- the > > called endpoint may not know the call signaling address to which to try to > > re-establish a socket connection, and it cannot assume 1720. Reverse call > > setup may not even be possible, given some network arrangements (including > > the usage of devices to traverse firewalls). > > > > There are several reasons to keep the channel open, too. This gives the > > endpoint the ability to perform supplementary services. If the channel is > > closed, the endpoints lose that functionality-- unless we can guarantee a > > way of re-establishing that channel. > > > > So, my advise to all implementers: never, never close the call signaling > > channel. > > > > Paul > > > > ----- Original Message ----- > > From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> > > To: "Satya T" <satyat(a)MIEL.MOT.COM> > > Cc: <h323implementors(a)imtc.org> > > Sent: Tuesday, December 21, 1999 8:52 AM > > Subject: Re: Closing Q.931 TCP connection.. > > > > > > > Satya, > > > > > > This is the subject of much current discussion, but the group within ITU > > SG16 > > > discussing robustness. Currently: > > > ReleaseComplete closes the call. > > > Closing the Q.931 TCP connection without ReleaseComplete does not close > > the > > > call if there is a separate active H.245 connection. > > > However, consideration is being given to the possibility of changing > this > > rule, > > > if no implementations can be found that deliberately close the Q.931 TCP > > > connection during a call. > > > > > > I strongly advise against deliberately closing the Q.931 TCP connection > > without > > > terminating the call, but as things currently stand > > > a) you are permitted do so as long as there is no gateway involved in > the > > call > > > (which you may or may not be able to know!!!) > > > b) you should cope with other parties in the call doing this (unless you > > or > > > they are a gateway!!!!!). > > > > > > Regards, > > > Chris > > > > > > Satya T wrote: > > > > > > > > Hi all, > > > > There's a gatekeeper routed call, > > > > and if the GK closes down the Q931 TCP connection, > > > > does it mean the call is closed? Consider the following cases : > > > > > > > > 1. When GK sends RELEASE complete before breaking > > > > down the TCP > > > > 2. When GK does NOT send RELEASE complete before > > > > breaking down TCP > > > > > > > > H.245 connection is established & ON directly between the EPs in > > > > both cases when the Q931 TCP is broken down. > > > > > > > > Is it considered closed in both the scenarios? or only in the former? > > > > > > > > regards > > > > Satya T > > > > > > > > > > > > -------------------------------------------------------------------------- > > > > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > > > > -------------------------------------------------------------------------- > > -------------------------------------------------------------------------- > - > > ------------------------------ > > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > > subscribe or unsubscribe from this list > > ------------------------------ > > -------------------------------------------------------------------------- > - > > > > > > > > > > > > > > --------------------------------------------------------------------------- > ------------------------------ > Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to > subscribe or unsubscribe from this list > ------------------------------ > --------------------------------------------------------------------------- -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

2 1

H.323 Mobility:MTD-17
by Edgar Martinez [1] 05 Jan '00

05 Jan '00

Dear All, MTD-17 has been added to the list of contributions. It will be put in the final agenda for Jan. 10, 2k meeting and review. MTD-17 from AT&T Title: Extension of H.323 Protocol for Mobility Abstract: This document describes the distinct areas for extension of H.323 mobility protocol --- The agenda for the meeting is in MTD-01e and it will be updated to MTD-01d by end of day Friday 06/01/2K so please send your contributions ASAP You may pick-up the documents in: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/SG16_Mobility/ or http://people.itu.int/~emartine/temp/SG16-mobility/All_Confernce_Call_meeti… -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

[Robustness] Updated Procedure
by Orit Levin 05 Jan '00

05 Jan '00

Hello Maureen and all the others! I am attaching the further expanded Procedure as an input for the conference call. (I may not be able to participate in the call due to a collision in my schedule, but RADVision's guys will be calling in.) Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: Closing Q.931 TCP connection..
by Boaz Michaely 04 Jan '00

04 Jan '00

Happy new Y2K ! Your consistent argueing against closing the Q.931 sig. channel, is appreciable, and I share your concern for many service scenarios. (I guess we'll talk more about this in February, which is why the ITU-SG16 list is copied) However, in the following scenario, it seems highly desireable to be able to close the sig. channel: (if this has been described before, please forgive my ignorance) Think of a scaleable IVR server farm which is implemented using multiple MG's, each capable of H.245, RTP/RTCP, and a very simple control protocol (H.248 ?). A single GRC GK, which is also an AnnexG Border Element is used as the single entry into this port-dense system. This GK may be addressed using LRQ from another domain (e.g. that of an ITSP). In addition, it publishes its own address using "SendSetup" type of addressing in the AnnexG templates that it publishes. Once a SETUP message comes in, the GK replies with an H.245 address of the applicable MG. Note that the GK has to be the point of call for SETUP, since it may use the information in the SETUP message for finding the applicable MG (i.e. using CLI and/or DNIS), as well as it performs load balancing on the MGs. Now the audio session is connected and the call takes place, while the MG handles the DTMFs and all the logic. Let's assume that there are no changes in the call routing from this point on (which is typically the case in, say, automatic banking systems etc.) GK intervention is not required any more until the call is done. It would be nice if the GK could get rid of the dangling Q.931 TCP connection, while the RTP call continues until it is disconnected by the human caller. If I understand correctly, this is a perfectly legitimate behaviour using the existing standard. (I trust this is true for all versions ?) Assuming this scenario is valid (have I overlooked anything ?) can we find a way to continue to support it while reducing the mess for other services ? Reinitiating the sig. channel in some way may not be a bad idea ? Finally, I must admit I do not understand Chris's comment about making sure the other party is not a GW. Why is that so? Boaz Michaely VocalTec Communications Ltd. +972 (9) 970-7869 email: boaz(a)vocaltec.com http://people.itu.int/~michaely "Paul E. Jones" <paul.jones(a)ties.itu.int> on 02/01/2000 12:04:50 AM Please respond to "Paul E. Jones" <paul.jones(a)ties.itu.int> To: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk>, "Satya T" <satyat(a)MIEL.MOT.COM> cc: h323implementors(a)imtc.org (bcc: Boaz Michaely) Subject: Re: Closing Q.931 TCP connection.. Folks, I would like to second Chris' comments. It really is a very bad idea to close the call signaling channel. This might have been important prior to H.245 tunneling and Fast Connect, but in my opinion, this just isn't necessary any longer. My chief complaint is that once the channel is closed, there's no guarantee one can re-open it. This is especially true on the receiving end-- the called endpoint may not know the call signaling address to which to try to re-establish a socket connection, and it cannot assume 1720. Reverse call setup may not even be possible, given some network arrangements (including the usage of devices to traverse firewalls). There are several reasons to keep the channel open, too. This gives the endpoint the ability to perform supplementary services. If the channel is closed, the endpoints lose that functionality-- unless we can guarantee a way of re-establishing that channel. So, my advise to all implementers: never, never close the call signaling channel. Paul ----- Original Message ----- From: "Chris Wayman Purvis" <cwp(a)isdn-comms.co.uk> To: "Satya T" <satyat(a)MIEL.MOT.COM> Cc: <h323implementors(a)imtc.org> Sent: Tuesday, December 21, 1999 8:52 AM Subject: Re: Closing Q.931 TCP connection.. > Satya, > > This is the subject of much current discussion, but the group within ITU SG16 > discussing robustness. Currently: > ReleaseComplete closes the call. > Closing the Q.931 TCP connection without ReleaseComplete does not close the > call if there is a separate active H.245 connection. > However, consideration is being given to the possibility of changing this rule, > if no implementations can be found that deliberately close the Q.931 TCP > connection during a call. > > I strongly advise against deliberately closing the Q.931 TCP connection without > terminating the call, but as things currently stand > a) you are permitted do so as long as there is no gateway involved in the call > (which you may or may not be able to know!!!) > b) you should cope with other parties in the call doing this (unless you or > they are a gateway!!!!!). > > Regards, > Chris > > Satya T wrote: > > > > Hi all, > > There's a gatekeeper routed call, > > and if the GK closes down the Q931 TCP connection, > > does it mean the call is closed? Consider the following cases : > > > > 1. When GK sends RELEASE complete before breaking > > down the TCP > > 2. When GK does NOT send RELEASE complete before > > breaking down TCP > > > > H.245 connection is established & ON directly between the EPs in > > both cases when the Q931 TCP is broken down. > > > > Is it considered closed in both the scenarios? or only in the former? > > > > regards > > Satya T > > > > -------------------------------------------------------------------------- > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > -------------------------------------------------------------------------- --------------------------------------------------------------------------- ------------------------------ Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------ ---------------------------------------------------------------------------

3 2

Re: H.323 Mobility: Geneva
by Roy, Radhika R, ALARC 04 Jan '00

04 Jan '00

Ed: I guess that you got the answer from Mobasser. Thanks, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Tuesday, January 04, 2000 9:20 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Mobility: Geneva > > Hi Radhika, > > Do you have any information (hotels, etc) on how to register to the > SG16 meeting for Feb. 7 in Geneva. > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.323 Mobility: Geneva
by Bahman Mobasser 04 Jan '00

04 Jan '00

Edgar (and anyone else looking for this information) The invitation is at: http://www.itu.int/itudoc/itu-t/com16/coll/007.html The following ITU circular contains a list of hotels. By sending the second form in the collective letter (above) directly to the hotel you obtain the ITU rate (usually -20%) http://www.itu.int/itudoc/itu-t/circ/circ4/180.html Bahman Mobasser "Edgar Martinez [1]" <martinze(a)CIG.MOT.COM> on 04/01/2000 15:19:37 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: Bahman MOBASSER/FR/ALCATEL) Subject H.323 Mobility: Geneva : Hi Radhika, Do you have any information (hotels, etc) on how to register to the SG16 meeting for Feb. 7 in Geneva. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

H.323 Mobility: Geneva
by Edgar Martinez [1] 04 Jan '00

04 Jan '00

Hi Radhika, Do you have any information (hotels, etc) on how to register to the SG16 meeting for Feb. 7 in Geneva. -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0