January 2000 - sg16-avd - lists.packetizer.com

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