- sg16-avd - lists.packetizer.com

[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

Test
by Theresa Mackenhauer 04 Jan '00

04 Jan '00

Test

1 0

[Robustness] minutes and next Telecon -- January 6 at 11AM EST US A
by Maureen Stillman 03 Jan '00

03 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 will post this draft to the mailing list prior to the teleconference for our review. Conference call number: 613-688-2795 The access code 5767#. You must enter the pound sign after the access code. Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Hope to talk with you on Thursday. Minutes of H.323 Robustness Teleconference - December 14, 1999 Prepared by Maureen Stillman, Nokia Next Teleconference: Will be held on Thursday, January 6 at 11AM EST USA. Nokia will host this again. Please send e-mail to maureen.stillman(a)nokia.com if you wish to join in. Agenda for the next 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. Action items from this teleconference: 1. Post meeting minutes to mailing list 2. Radvision to post draft submission to the mailing list before the Jan. 6 teleconference. 3. Everyone needs read the draft submission so we can discuss it during the teleconference. Attending the 11/16 teleconference: Rich Bowen rkbowen(a)cisco.com Paul Jones Paul.jones(a)ties.itu.int Orit Levin orit(a)radvision.com Kumar, Vineet vineet.kumar(a)intel.com Robert Callaghan Robert.Callaghan(a)ICN.siemens.com Maureen Stillman maureen.stillman(a)nokia.com Jorg Ott jo(a)tzi.uni-bremen.de Michael Fortinsky Michael_Fortinsky(a)vocaltec.com Sasha Ruditsky at Radvision (please send me your e-mail address) Unable to attend, but submitted scenarios: Radhika Roy rrroy(a)att.com Submissions for the teleconference: Radvision AT&T Nokia, Security and Robustness Summary of Teleconference: Given that submissions for the SG-16 Geneva meeting are due on January 27, we decided to discuss short to medium term robustness solutions. At the Geneva meeting, we have the potential to add robustness solutions to the draft of H.323 version 4. Radvision agreed to draft a submission for comment and debate at our next teleconference scheduled for January 6. The intent is to submit a technical contribution on robustness by the January 27th deadline. Discussion: Scenario: We are focusing on the following scenario: Corporate Environment - 1 gatekeeper; all calls are gatekeeper routed; H.225 up and running; might be using fastconnect; two endpoints have a call in progress Gatekeeper goes down or fails - the two endpoints lose the call signaling channel We agree that such a call needs to be continued - how this should be done is a problem that needs to be solved. We have a redundant GK that we want to use. How can we recover the call from this scenario? If no component has any robustness mechanisms then the TCP connection should be terminated by the endpoint. Otherwise, if robustness mechanism is in place, we should base the solution on that fact that both endpoints as well as the gatekeeper are robust aware. The redundant gatekeeper starts the robustness procedure and will open new TCP ports. The endpoints will understand this based on the CALL ID value (see discussion on CALL ID below). On keeping the state of the call: We need to transmit the call state between the GK and endpoint. Should we keep all messages or some messages? Last transaction? H.450 is designed to be "fail safe" meaning that in the event of a problem, the service can fail but the call will not fail. We can't assume that we can restore the "exact state" of the call because unfortunately this is not deterministic. We should ignore the case in which someone is pushing keypad buttons, by assuming that they will just push the buttons again if they don't get the right response. We need a set of deterministic rules to determine what happens when there is a failure so we can reconstruct the call state. There will be a proposed procedure to do this. "Special protocols" such as H.450 must be "fail safe". H.225 has a status message. What happens with H.245 that doesn't have the equivalent of a status message? The standard currently states that if H.245 is lost then the call is terminated. We need to define extensions to H.245 to support ruggedness. Discussion of Call IDs: We need to determine what ID/IDs will be used for recovered calls. For example, will the conference ID or the call ID remain the same or will it be different for the recovered call? Will I get billed twice for the same call? There are potentially two different cases: 1. Maintain the same call by using the same Call ID 2. Clear resources and have a new call with a new Call ID Robert Callahan reported that there is currently an ad hoc group in Study Group 16, which is discussing additional IDs associated with a call for various purposes including billing. They are talking about adding IDs for billing supplementary services, for example. The conclusion was that we should wait for this group to propose their solution before deciding how CALL IDs for robustness should fit in. Pros and Cons of Application Layer Restart: Suppose we decide to design a restart mechanism that involves the endpoints. Application layer restart is OK for the endpoint that knows that there has been a failure, but what about an endpoint that doesn't know? How does it distinguish between a new call coming in and a call that is being restarted? What if both endpoints determine that there is a problem and both decide to restart the call? **** end of minutes **************** -- maureen 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

Re: FW: Some H.225 Annex G questions (LONG)
by Michael Fortinsky 02 Jan '00

02 Jan '00

Hi Ellen, I am leading the Annex G implementation in VocalTec - working closely with Boaz Michaely who is the editor of H.225 Annex G. We think that your questions may be interesting to the mailing lists, so we are posting our answers. This will hopefully encourage further discussions - we need to decide whether we need a new version of AnnexG for the upcoming SG16 meeting in February. > ---------- > From: SRD Zhang Xiao > Sent: Tuesday, December 14, 1999 11:24 AM > To: 'Boaz_Michaely(a)vocaltec.com' > Subject: Some questions > > Hi Boaz, > > 1. Cache mechanism. 1.7.1.2 Receiving Descriptors says using > DescriptorUpdate message to update the descriptor. 1.7.1.3 Receiving > Response to Specific Queries says template can also be cached when using > AccessRequest. The problem is: AcessRequest only caches partial > descriptor, I mean some templates. When one template is updated, I can't > assign the template with its desciptor, I don't know who's its desciptor, > So I can't send DescriptorUpdate message to other BEs who cached this > template. What can I do for this case? > There are two kinds of templates that can be maintained as part of a descriptor: (a) those that contain sendAccessRequest (b) those that contain sendSetup Let's use Section 1.9.1 (Figures 9 and 10) as an example that illustrates how we understand the situation. (The same applies to the clearing house example in 1.9.2). In the example, BE(A) sends an accessRequest to BE(B) and receives a template in the accessConfirmation. Presumably, this will be a type-(b) template (one that contains sendSetup). There is no overlap between this template and the templates contained in the list of descriptors (if there was, BE(A) would not have sent the accessRequest in the first place). This response may be cached - in the example it is. It is correct that there is no mechanism to update this. It is the responsibility of the border element that issued the template to ensure that the template remains valid for the duration of the ttl. > 2. 1.7.1.3 Receiving Response to Specific Queries describe a BE coupled > with the firewall. When an AccessRequest arrives, it shall respond two > templates: one with a short lifetime owning Setup type, others with > AccessRequest type for other AliasAddress. Could you give me a bit more > detailed explanation about that? > This is a good question - maybe somebody (Glen?) can enlighten us? > 3. I found something conflict in 1.9.2.1 Exchange of Zone Information. In > Figure 14, why shall BED request BECH d1 and d2, BEE request BECH d3 > and d4 ? I consider BED's capability is d1 and d2, BEE 's capability > is d3 and d4, they're staticlly configured when initializing. Why need > they send DescripotrRequest? > You're right - there seem to be a few mistakes in the table and the flow diagram in section 1.9.2. We would recommend (to the editor :-) to introduce the following corrections: In the Table: - the template definition for Administrative Domain E should read "d3" and "d4" In Figure 14: - the DescriptorRequests from BE(D) should be for "d3" and "d4" - the DescriptorRequests from BE(E) should be for "d1" and "d2" In addition, the following editorial change should be made to Figures 8 and 14: - change "DescriptorIDReqConf" to "descriptorIDConfirmation" - change "DescriptorRequestConfirmation" to "descriptorConfirmation" > 4. I aslo found some conflicts in 1.9.2.2 Placing a Call.In Figure > 15,16,and 17, after initialization, BECH owns all Descriptors information, > when resolving a telephone number, an AccessRequest to BECH can finish > this procedure.Why need BECH send AccessRequest to BED,or BEE send > AccessRequest to BED? > According to descriptor "d1", an accessRequest must be sent to BE(D) - regardless of who knows about "d1". Actually, in this example we think there is a different mistake. In this case, BE(E) would send an accessRequest directly to BE(D) and bypass the clearing house. We think the intent of the example was to show how the clearing house can control call setup (e.g., for billing purposes). To correct this, the clearing house would need to publish its own set of descriptors (which indicate that sendAccessRequest should always go back to itself). ===> Unless anyone disagrees, we will recommend that the editor change this too. > 5. About AccessRequest definition. is AccessRequest->SourceInfo caller info > or access requester info? Could you give me some explanation? This is a good question. Annex G left this unspecified and clearly service providers will need to decide if they want to use this information and how. For example, the iNow! interdomain profile states that the SourceInfo should include the domainInfo and endpointType (presumably of the calling party). This works well in a distributed or full mesh configuration (section 1.5.2 of Annex G), but in the clearing house model, it is not specified what the clearing house should fill in for these fields in the accessRequest that it sends. The iNow! interdomain profile may be found at: ftp://ftp.imtc-files.org/imtc-site/inow-ag/iNOW_Interdomain_Profile_V2.1-AG -Approved.doc > 6. Why need Annex G? RAS is good, why introduce Annex G? RAS was not designed with interdomain communications in mind. For example, there is no discussion of how dialing plans or billing-related information can be transferred between domains. Annex G fills in many of these holes (for example, via AddressTemplates and UsageIndications). We hope this helps. Michael Fortinsky mike(a)vocaltec.com Boaz Michaely boaz(a)vocaltec.com

2 1

Information Required about H.246
by Deepak Wadhwa 30 Dec '99

30 Dec '99

Can somebody please point me to the latest recommendation or contribution related to H.323 - ISUP interworking. Thanks, -- +----------------------------------+-----------------------------------+ |Deepak Wadhwa | TRILLIUM DIGITAL SYSTEMS, INC. | |email: deepak(a)trillium.com | 12100 Wilshire Blvd.,Suite 1800,| |tel: +1(310)-584-0112(home) | LA, CA 90025-7118. | | +1(310)-442-9222(work) | | |fax: +1(310)-442-1162(work) | http://www.trillium.com | +----------------------------------+-----------------------------------+

2 1

Re: H.323 Mobility Works: SG16 Reflector vs. Conf Call
by Roy, Radhika R, ALARC 30 Dec '99

30 Dec '99

Hi, SG16 Members: I like to add a minor correction of my earlier email (copy enclosed). Thanks to Boaz Michaely for pointing me this. Per my email, I mentioned about the US SG-D meeting. This meeting is internal to the US for review any contributions that might be going from the US to the Sg16 meeting. However, a Rapporteur represents the ITU position and their contributions are submitted to the ITU. However, any country can also review those contributions to formulate their own internal views if those documents are available. Please read my US SG-D meeting in this context. Best Regards, Radhika R. Roy > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Friday, December 24, 1999 1:50 PM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: H.323 Mobility Works: SG16 Reflector vs. Conf Call > > Hi, SG16 Members: > > I like to appeal to you all that we have only two conference calls left > for the H.323 Ad Hoc Mobility group. The time is very precious to advance > our work. The editor of H.323 Annex H needs to produce a meaning document > so that the Q.13 Rapporteur can take this as a contribution to the SG16 > meeting for determination in the upcoming Feb'00 SG16 meeting. Since a > Rapporteur is from the US, the document needs to be submitted to US State > Department on January 21st in the SG-D meeting. > > How can we expedite our progress? I have some thoughts that may allow us > to make a quick progress. We like to use two media for communications: 1. > SG16 email reflector and 2. Ad Hoc Mobility Group Conference call. > > How do we divide our works in these two media of communications? I propose > that some items can better be addressed via emails. > > For example, we spent a lot of time in the last conference call whether we > should take one document. If we do, how the document will be handled by > the editor and/or Rapporteur. This sort of discussions can easily be > addressed via the email. Moreover, we have done this in many cases. For > example, H.225.0 Annex G, H.248, and many other meetings. An editor or > Rapporteur knows how to deal with this situation. A editor will produce a > document based on consensus made in the meetings on behalf of the > Rapporteur, and a Rapporteur will decide whether the document can be taken > as Rapporteur's contribution in the SG meeting. Of course, the document > will contain two parts: > > 1. The part that has been agreed before the conference call and > 2. The other will include as follows: > A. What has been accepted to MODIFY from the original agreed > version, if any and > B. What has been added as NEW to the proposed documents. > > If necessary, the editor may also contact the Rapporteur to have > clarifications further. > > In another example, suppose we have a document agreed upon in the last Red > Bank SG16 meeting. Someone wants to have some comments to modify that > document that is primarily from the editorial point of view. This work can > be done via email as well. In this context, I will refer to Alcatel's > contribution - MTD 107b. It wants some modifications and additions of the > editor's document. We can handle this contribution via email as well (I > also plan to send my comments via so that we do not need to spend time to > address this during the conference call). > > The next question is: What do we want to discuss during the conference > call? > > A simple answer is to address new areas that advance our understanding to > provide solution related to the H.323 mobility. For example, one of the > Nokia's contribution addresses the reference architecture of H.323 > including mobility. This has been a new area towards solutions and, we > have made progress in this area as well. > > My appeal to all members of the SG16 members is: Let us address > contributions that advances the solution of the H.323 mobility problems in > the upcoming conference calls. > > I have provided a contribution showing that there are three phases in this > area: 1. Extension of H.323 for supporting mobility, 2. H.323 backend > services related to mobility, and 3. Interworking between H.323 system > (mobile/non-mobile) and Non-H.323 system (mobile/Non-mobile). > > Let us move on! > > Best regards, > Radhika R. Roy, AT&T > H.323 Ad Hoc Mobility Group > +1 732 420 1580 > rrroy(a)att.com >

1 0