- sg16-avd - lists.packetizer.com

Upload of APC-1773
by Callaghan, Robert 02 May '00

02 May '00

APC-1773 -- Additional Network Function Common Information has be uploaded as apc-1773.zip ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: H.450.2 ASN.1 related
by Klaghofer Karl ICN SIB NL D1 02 May '00

02 May '00

Hani, Please consider that a similar modification has been made to the H.450.x standards beginning with H.450.4. We did not change the H.450.2 and .3 in order to guarantee backwards compatibility. Beginning with H.450.4 the MSI information to standardized opertations are defined as SEQUENCE SIZE (0..255) OF MixedExtension. MixedEntension type is then defined as any combination of H.225.0 like nonStandardParameter type of extensions and ROS Object class extensions. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: El-Gebaly, Hani [SMTP:hani.el-gebaly@INTEL.COM] > Gesendet am: Friday, April 28, 2000 19:04 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450.2 ASN.1 related > > H.323 experts, > > The ASN.1 code for H.450.2 contains the following structure: > "argumentExtension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter } > OPTIONAL," > duplicated inside many larger structures such as CTInitiateArg, > CTSetupArg, CTIdentifyRes, CTUpdateArg, SubaddressTransferArg, etc. > > Feeding the code as is into the ASN.1 compiler will result in multiple > _choice structures (_choice1, _choice2, _choice3, etc.) for the same exact > structure: > "CHOICE {extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter } > OPTIONAL" > > We can do some optimization and save some code (desperately needed for > embedded platforms) by modifying the ASN.1 code and defining a new > structure as follows: > ExtensionASN ::=CHOICE > { > extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter > } > > And use ExtensionASN structure in all the CTXArgument structures that use > the above structure, for example: > CTInitiateArg ::= SEQUENCE > { > callIdentity CallIdentity, > reroutingNumber EndpointAddress, > argumentExtension ExtensionASN > OPTIONAL, > ... > } > Since implementers should not touch the ASN.1 code on their own and the > H.450.2 document will have to go through the ITU process of producing a > new revision to have a fix like this, my questions are: > Does anyone see any problem with this optimization? Will a modification > like this have any effect on bits going on the wire (it shouldn't)? Can > this proposal break backward compatibility? > Is there a compelling reason for writing the structures the way they are > in the H.450.2 document? > > Thanks for all your responses > Hani ElGebaly > > Intel Corporation > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution submission and hotel room
by Sakae OKUBO 02 May '00

02 May '00

Dear Mr. Skjaeran, >Please allocate a document number for "Draft white paper for H.323 Annex K". APC-1811 has been allocated to your contribution. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Document number allocation
by Sakae OKUBO 01 May '00

01 May '00

Dear Jill Caugherty, Dear Orit Levin, In response to your requests, the following APC numbers have been allocated to your contributions: APC-1802 Cisco Fast Connect SDLS/Fast Connect Overview APC-1803 Cisco Synchronization of RSVP APC-1804 Cisco Proposal for Optimizing Use of Existing Channels for Multiple Calls APC-1805 Cisco Addition of multipleCalls field in ACF, LCF, and RRQ messages APC-1806 Cisco Clarifications to Annex E APC-1807 Cisco Addition of session ID to Annex E Ack and Nack messages APC-1808 Cisco ModeRequest Procedure for T.38 Fax APC-1809 RADVision Missing fields in H.225.0 messages APC-1810 RADVision SDLs for Robustness Procedure The current list of registered documents is available as: http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000502.html http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000502.doc Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ASN.1 restrictions in H.225.0
by Rich Bowen 30 Apr '00

30 Apr '00

Dale Skran asked me to document the ASN.1 restrictions that we use in H.225.0, as a guide to contributors. If I understand correctly, there was an understanding among the early contributors that some ASN.1 constructs were forbidden, to keep the ASN.1 simple. He said some of the old timers in Q.13/Q.14 should be able to help out with this. Does anyone remember any of these restrictions? I would appreciate any information. Thanks, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] conference call May 4 11AM EST USA
by Maureen Stillman 30 Apr '00

30 Apr '00

Please join us for the next robustness conference call on May 4 at 11AM EST USA. The number to call is: (613)688-2795 The passcode is: 0695# You must enter the pound sign after the passcode. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC Numbers Requested
by Sakae OKUBO 29 Apr '00

29 Apr '00

Dear Mr. Taylor, > Please allocate one APC number for "Megaco/H.248 Errata". I believe > I need another for "H.248 As Modified By Errata", unless Mr. Segers > is planning to submit that (I have copied him on this request). APC-1800 and APC-1801 have been allocated to your two contributions. I have received no indication for the second one from anyone else. I have put the same source as the first one (Chair, IETF Megaco Working Group) to it. Please advise me if it should be otherwise. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contribution submission and hotel room
by Sakae OKUBO 29 Apr '00

29 Apr '00

Dear Q12-14/16 experts, This is to remind you the deadlines of the contribution submission for the upcoming Osaka meeting, 15-19 May 2000. /// Registration of the document: by 5 May (Friday) /// /// Distribution of the document: by 8 May (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// The current list of registered documents is available as: http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000430.html http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000430.doc Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Osaka meeting attendance
by Sakae OKUBO 29 Apr '00

29 Apr '00

Dear Q11, Q12-14, Q15 experts, Please note that all the block-reserved rooms have been returned to the hotel. If you sent your hotel room application, but have not received a confirmation number by e-mail, please advise the secretariat (Ms. Noriko Hosokawa, e-mail: nonko(a)giti.waseda.ac.jp) If you are coming to Osaka, but have not registered yet, please advise the secretariat. We will try to find a hotel room for you. PS to G Sullivan, could you please post this message to your reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Submission: APC-1772: On H.323 Robustness Architecture Using DDP and SCTP
by Qiaobing Xie 28 Apr '00

28 Apr '00

Mr. Okubo, Please find the attached submission of our contribution APC-1772. Thank you. Regards, -Qiaobing Xie Motorola, Inc. U.S.A.

1 0

H.450.2 ASN.1 related
by El-Gebaly, Hani 28 Apr '00

28 Apr '00

H.323 experts, The ASN.1 code for H.450.2 contains the following structure: "argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL," duplicated inside many larger structures such as CTInitiateArg, CTSetupArg, CTIdentifyRes, CTUpdateArg, SubaddressTransferArg, etc. Feeding the code as is into the ASN.1 compiler will result in multiple _choice structures (_choice1, _choice2, _choice3, etc.) for the same exact structure: "CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL" We can do some optimization and save some code (desperately needed for embedded platforms) by modifying the ASN.1 code and defining a new structure as follows: ExtensionASN ::=CHOICE { extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } And use ExtensionASN structure in all the CTXArgument structures that use the above structure, for example: CTInitiateArg ::= SEQUENCE { callIdentity CallIdentity, reroutingNumber EndpointAddress, argumentExtension ExtensionASN OPTIONAL, ... } Since implementers should not touch the ASN.1 code on their own and the H.450.2 document will have to go through the ITU process of producing a new revision to have a fix like this, my questions are: Does anyone see any problem with this optimization? Will a modification like this have any effect on bits going on the wire (it shouldn't)? Can this proposal break backward compatibility? Is there a compelling reason for writing the structures the way they are in the H.450.2 document? Thanks for all your responses Hani ElGebaly Intel Corporation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC number request for H.248 Annex F
by Sakae OKUBO 27 Apr '00

27 Apr '00

Dear Mr. Hellstrom, The following APC numbers have been allocated to your two contributions: APC-1798 >Title: H.248 Annex F, Facsimili, Text and Call Discrimination packages white >draft proposal >Source: Editor. Gunnar Hellstrom, Ericsson >Purpose: Proposal APC-1799 >Title: H.248 Annex F issues >Source: Editor. Gunnar Hellstrom, Ericsson >Purpose: Discussion Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC numbers for Osaka meeting
by Sakae OKUBO 27 Apr '00

27 Apr '00

Dear Mr. Fortinsky, In response to your request, the following APC numbers have been allocated to your two Editor contributions: APC-1796 >(1) H.225.0 Annex G version1 - with corrections > This is the same version that was recently sent out on the reflector. > It has never been released as an official document. APC-1797 >(2) H.225.0 Annex G version 2 - draft > This version contains the corrections that apply to version 1 and >the changes introduced during the previous Geneva meeting. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1783 and 1784
by Selvam Rengasami 27 Apr '00

27 Apr '00

Dear Q.14/16 participants, For your information, I have uploaded two files providing two editor's contributions to the Osaka meeting for Q.14. 1. APC-1783 : H.248, Annex J ("Dynamic Tone Definition Package"). This is the determined text from the Geneva Feb 2000 SG 16 Meeting 2. APC-1784 : H.248, Annex K ("Generic Announcement Package"). This is the determined text from the Geneva Feb 2000 SG 16 Meeting Unfortunately, I will not be attending the Osaka meeting as I will be on vacation. However, Mr. Zacharias will be able to address questions on these documents at the meeting as he is a co-editor for these documents. -Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 Fax: +1 732 758 4435 E-mail: srengasa(a)telcordia.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC Numbers
by Sakae OKUBO 27 Apr '00

27 Apr '00

Dear Mr. Jones, The following APC numbers have been allocated to your eight contributions. APC-1788 H.323v4 Draft APC-1789 Implementers Guide Draft APC-1790 Indicating Frames/Samples per RTP Packet APC-1791 Call Proceeding / Facility Issues APC-1792 empty fastStart versus fastConnectRefused APC-1793 When to include perCallInfo in an IRR APC-1794 New Proposed LRJ reason "resourcesNotAvailable" APC-1795 URQ to contain Alternate Gatekeeper Information Please advise me the source of APC-1790 through 1795. Each of them might be from Editor (P Jones) or from Cisco? For your information, the current list of registered documents is attached. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Issue in H.323 robustness not addressed by SCTP/DDP
by Archana Nehru 27 Apr '00

27 Apr '00

Hello, We think that SCTP/DDP by itself is not a complete solution for robustness (see PROBLEM B below) and certain changes need to be made in the H.323 layer to achieve robustness. For the sake of clarity, we restate the issues we need to address in order to achieve robustness: In the current H.323 specs, if the TCP connection for a H.323 call goes down, the call is lost. To overcome this problem, we need: A. Fail over mechanism Whenever an endpoint detects that the other side is down (e.g.: TCP connection failure/ no ACKs received in Annex E) the endpoint can save an active H.323 call, if it knows about a "recovery H.323 address". The "recovery address" is the back-up address that the endpoint can use to re-establish a TCP connection (for TCP) or to resend Annex E data (UDP). From the endpoint's point of view, the "recovery address" represents a node that has enough information about the H.323 call to continue processing as if the failure had never occurred The failure in the node could have been one of the following types: 1. Transport failure: e.g. failed NIC, congested network. 2. Node failure: e.g. the entire gatekeeper fail. In this case, we need a synchronization mechanism between the gatekeeper and its backup so the active calls can be saved. B. Handle Call State Synchronization We need to make sure that both legs of a H.323 call are in sync. When an intermediate node (e.g. Gk) fails, messages from an endpoint can get lost. e.g.: Take the example of a lost RELEASE COMPLETE in the following scenario: (CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 EP1 sends a RELCOMPLETE to EP2 via the GK. The GK crashes, before forwarding the RELCOMPLETE from EP1 to EP2. As a result EP1 thinks the call is released, while as the EP2 thinks the call is up. As Paul has pointed out: several H.245 messages are problematic-- especially those related to conferencing, such as chair control, terminal join/left, terminal you are seeing, etc. UserInputIndication and any other "indication" message that does not require a response is an issue. POSSIBLE SOLUTION(s): --------------------- Solution to Problem A: ---------------------- This problem can be solved using SCTP/DDP or modifying Annex E to include alternate addresses. Solution to PROBLEM B: ---------------------- This problem cannot be solved using SCTP/DDP as it is inherent in the H.323 protocol. If we take the same example as above: (CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) what happens if the GK fails just after its SCTP layer finished sending an SCTP-ACK for the RELCOMPLETE message to EP1. EP1 receives the SCTP-ACK and therefore considers the call released but EP2 never receives the RELCOMPLETE message. It is important to note here that "checkpointing" in the H.323 layer of the GK will not help since the ACK at the SCTP level is generated before RELCOMPLETE message is delivered to the H.323 layer of the GK. So we can solve the problem by having an "END-to-END acknowledgement mechanism" to make sure that EP1 and EP2 are in sync even when the intermediate node fails. One approach as suggested by Paul is to modify Annex E to have end-to-end acknowledgement. We want to point out that actually this is a H.323 layer problem. By introducing end-to-end ack into Annex E, we will be trying to solve a protocol layer problem by making modifications in the transport layer mechanisms. The problem of synchronization comes from the fact that the H.323 layer does not have an ACK for every message that is sent out. Alternatively, if we introduce an ACK packet for every H.323 message that currently has no ACK (e.g: H.245 commands/indications or H.225 RELEASE COMPLETE), we can address the problem cleanly. This ACK message will be supported only by the nodes that support robustness. Unlike the Annex-E approach, this approach is independent of the transport layer protocol layer below H.323, and can also be applied to SCTP/DDP. Comments are welcome on this issue. Regards, Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 4

Re: Issue in H.323 robustness not addressed by SCTP/DDP
by Archana Nehru 27 Apr '00

27 Apr '00

Paul, Thanks for replying. Please seem my comments below: -Archana >The ACK packet certainly follows the line of thinking that I >had. However, >one issue with implementing this approach is that there are no >fields in >H.323 to provide a "sequence number". I suppose this could easily be >overcome. Well, if you are concerned about retransmissions, may be the endpoints could just look at the "callId" in the ACK, look at the "session-state" and conclude that the packet is just a retransmission. > >Here's a thought: how about introducing a new session layer between the >transport and below the H.323 application? This session layer would >actually encode messages in a special format for transmission >on the wire. >For example, for TCP, we could modify the TPKT header and the >payload to >carry not only the H.323 message, but also sequencing data and other >information. We can allow fail-over addresses to be carried >in this layer >and allow this layer to completely handle connection recovery. Well let me put it this way. What do we gain by doing this?. Wouldnot it be simpler to modify H.323 procedures by introducing an ACK message itself (probably use some modified FACILITY?) and do it in a clean manner. Anyway, all we need in H.323 is an ACK from the peer, if the requester indicates that it needs an ACK. This could be decided as part of the connection set up procedure itself..so an endpoint would know before hand whether "a particular" node supports robustness or not. The message we decide to use will be optional and existing applications would just have to learn to ignore it, if they dont want to support robustness. That is not a big change..is it?.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: FW: Issue in H.323 robustness not addressed by SCTP/DDP
by Archana Nehru 26 Apr '00

26 Apr '00

hi , Please see my comments below: -Archana >> >> (CRASH) RELCOMPLETE >> EP2 <-------------- GK <------------ EP1 >> (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) >> >> EP1 sends a RELCOMPLETE to EP2 via the GK. >> >> | H.323 layer of GK| >> | | ^ | >> | | | | >> ---|------------|--- >> Outgoing | | DDP/SCTP | | >> RELCOMP<--------- ------------ Incoming RELCOMP >> | | >> -------------------- >This is what most likely will happen with DDP/SCTP: > >Without receiving a RELCOMP, EP2's H.323 layer will time-out and resend >RELEASE, and the resend will prompt DDP layer at EP2 to detect the >faulted GK and route the resent RELEASE to the alternate GK. Of cause, >the alternate GK needs to be able to fetch the call state info of this >call from, for example, a shared network memory containing checkpointed >call state data and continue the call release sequence of this call. >This re-sent RELEASE may surprise EP1 a little; it appears as a >duplicate to EP1. But EP1 simply needs to reply another RELCOMP to EP2, >DDP will route it through the alternate GK of cause. > >From application's view, except a time-out at EP2 and a duplicate >RELEASE at EP1, the call flow continues. The take-over is carried out >transparently by DDP and SCTP. I think you are confusing the RELCOMPLETE here with the RELCOMPLETE as used in Q.93B. In H.323 there is no RELEASE message..there is only RELEASE COMPLETE. So in the above example, EP1 is the end that wants to release the call and sends a RELEASE COMPLETE (instead of RELEASE as in Q.93B)and no response is required to this RELEASE COMPLETE. So the moment EP1 's SCTP delivers the RELEASE COMPLETE message to the GK, the EP1 considers the call released. And this is exactly the problem we were trying to point out- the problem of no ACKs. Like you pointed out , if there had been a pair (RELEASE /RELEASE COMPLETE)for every message, the problem would have been sorted out by itself. There are also other H.245 messages which have no ACKs where we will have a similar problem. So we need an ACK for every message at the H.323 layer also. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: Issue in H.323 robustness not addressed by SCTP/DDP
by Archana Nehru 26 Apr '00

26 Apr '00

2 1

Re: Issue in H.323 robustness not addressed by SCTP/DDP
by Archana Nehru 26 Apr '00

26 Apr '00

Qiaobing, Could you explain how SCTP/DDP layer below would handle the PROBLEM B. My understanding of the SCTP/DDP is based on the internet draft that exists right now. Just as to make clear that we are in sync about the problem, let me explain our view of SCTP/DDP functionality for this particular problem of H.323 robustness. a) SCTP will help H.323 to route data to multiple IP addresses belonging to the SAME node(multi-homed host). b) DDP extends this functionality by allowing an H.323 endpoint to send data not only to multiple IP addresses belonging to the SAME node but between physically DIFFERENT nodes .This is achieved by translating a "NAME" to a group of IP addresses. If there is any other functionality in this context that is relevant for the discussion here, please do point it out. Now coming to problem B that we had stated (I am modifying the diagram for clarity): (CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) EP1 sends a RELCOMPLETE to EP2 via the GK. | H.323 layer of GK| | | ^ | | | | | ---|------------|--- Outgoing | | DDP/SCTP | | RELCOMP<--------- ------------ Incoming RELCOMP | | -------------------- The SCTP/DDP layer receives the RELCOMP and sends an ACK back to the EP1.so SCTP/DDP's job is over.Now the SCTP/DDP layer sends the RELCOMP message to the H.323 layer and the H.323 layer crashes.So there is no context of that RELCOMP message on the STANDBY. So our point is that this problem is outside the domain of the SCTP/DDP. Btw, are you suggesting that we do a "checkpointing" in the H.323 layer for every message we received? I am sure you will agree that that will be very expensive. -Regards Archana >-----Original Message----- >From: Qiaobing Xie [mailto:xieqb@CIG.MOT.COM] >Sent: Wednesday, April 26, 2000 1:22 PM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Re: Issue in H.323 robustness not addressed by SCTP/DDP > > >Archana, > >One thing you might have missed is that the DDP/SCTP fault-tolerance >model is designed to provide robustness to the application in a >*transparent* fashion. The state synchronization issue (your PROBLEM B) >is a no-issue to DDP/SCTP model. In our model, a back-up GK will >automatically kick in and continue forwarding the RELCOMPLETE to EP2, >without either EP even noticing that the failure ever happened at all! >There is NO application involvment required in this scenario. > >-Qiaobing > >Archana Nehru wrote: >> >> Hello, >> >> We think that SCTP/DDP by itself is not a complete solution >> for robustness (see PROBLEM B below) and certain changes >> need to be made in the H.323 layer to achieve robustness. >> For the sake of clarity, we restate the issues we need to address in >> order to achieve robustness: >> >> In the current H.323 specs, if the TCP connection for a >H.323 call goes >> down, the call is lost. To overcome this problem, we need: >> >> A. Fail over mechanism >> >> Whenever an endpoint detects that the other side is down >(e.g.: TCP >> connection failure/ no ACKs received in Annex E) the endpoint can >> save an active H.323 call, if it knows about a "recovery H.323 >> address". >> >> The "recovery address" is the back-up address that the >endpoint can >> use to re-establish a TCP connection (for TCP) or to >resend Annex E >> data (UDP). From the endpoint's point of view, the >"recovery address" >> represents a node that has enough information about the >H.323 call >> to continue processing as if the failure had never occurred >> >> The failure in the node could have been one of the >following types: >> >> 1. Transport failure: e.g. failed NIC, congested network. >> >> 2. Node failure: e.g. the entire gatekeeper fail. In this case, we >> need a synchronization mechanism between the gatekeeper and its >> backup so the active calls can be saved. >> >> B. Handle Call State Synchronization >> We need to make sure that both legs of a H.323 call are >in sync. When >> an intermediate node (e.g. Gk) fails, messages from an >endpoint can >> get lost. e.g.: Take the example of a lost RELEASE COMPLETE in the >> following scenario: >> >> (CRASH) RELCOMPLETE >> EP2 <-------------- GK <------------ EP1 >> >> EP1 sends a RELCOMPLETE to EP2 via the GK. The GK crashes, before >> forwarding the RELCOMPLETE from EP1 to EP2. As a result EP1 thinks >> the call is released, while as the EP2 thinks the call is up. >> >> As Paul has pointed out: several H.245 messages are problematic-- >> especially those related to conferencing, such as chair control, >> terminal join/left, terminal you are seeing, etc. >> UserInputIndication and any other "indication" message >that does not >> require a response is an issue. >> >> POSSIBLE SOLUTION(s): >> --------------------- >> >> Solution to Problem A: >> ---------------------- >> This problem can be solved using SCTP/DDP or modifying Annex E to >> include alternate addresses. >> >> Solution to PROBLEM B: >> ---------------------- >> >> This problem cannot be solved using SCTP/DDP as it is inherent in the >> H.323 protocol. If we take the same example as above: >> >> (CRASH) RELCOMPLETE >> EP2 <-------------- GK <------------ EP1 >> (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) >> >> what happens if the GK fails just after its SCTP layer >finished sending >> an SCTP-ACK for the RELCOMPLETE message to EP1. EP1 receives the >> SCTP-ACK and therefore considers the call released but EP2 never >> receives the RELCOMPLETE message. It is important to note here that >> "checkpointing" in the H.323 layer of the GK will not help >since the ACK >> at the SCTP level is generated before RELCOMPLETE message is >delivered >> to the H.323 layer of the GK. >> >> So we can solve the problem by having an "END-to-END acknowledgement >> mechanism" to make sure that EP1 and EP2 are in sync even when the >> intermediate node fails. >> >> One approach as suggested by Paul is to modify Annex E to have >> end-to-end acknowledgement. We want to point out that >actually this is a >> H.323 layer problem. By introducing end-to-end ack into Annex E, we >> will be trying to solve a protocol layer problem by making >modifications >> in the transport layer mechanisms. The problem of >synchronization comes >> from the fact that the H.323 layer does not have an ACK for every >> message that is sent out. >> >> Alternatively, if we introduce an ACK packet for every H.323 message >> that currently has no ACK (e.g: H.245 commands/indications or H.225 >> RELEASE COMPLETE), we can address the problem cleanly. This >ACK message >> will be supported only by the nodes that support robustness. >Unlike the >> Annex-E approach, this approach is independent of the transport layer >> protocol layer below H.323, and can also be applied to SCTP/DDP. >> >> Comments are welcome on this issue. >> >> Regards, >> Archana >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC document numbers
by Sakae OKUBO 26 Apr '00

26 Apr '00

Dear Selvam Rengasami, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1783 >1. H.248, Annex J ("Dynamic Tone Definition Package"). This is the >determined text from the Geneva Feb 2000 SG 16 Meeting APC-1784 >2. H.248, Annex H ("Generic Announcement Package"). This is the >determined text from the Geneva Feb 2000 SG 16 Meeting I provisionally put "Telcordia" as the source in my list, but I wonder if "Editor (who?)" is more appropriate. Advice from you or Glen is appreciated. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Robustness] - final reminder conference call April 27 11AM EST U SA
by Maureen Stillman 25 Apr '00

25 Apr '00

There will be a robustness conference call on Thursday, April 27 at 11AM EST USA. The phone number to call is: 613-688-2795 The passcode is: 2811# You must enter the pound sign after the passcode. Agenda: 1. continue discussion of SCTP/DDP vs Annex E discussion 2. Plans for Osaka 3. next meeting Please join us. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Osaka meeting registration
by Sakae OKUBO 25 Apr '00

25 Apr '00

Dear SG16 colleagues, This is a message from the meeting secretariat. Please find attached a list of registered participants (as of 17:00 Tuesday, Tokyo time) of the Q11-15 Rapporteur meeting in Osaka during 15-19 May 2000. Please advise Ms. Noriko Hosokawa (e-mail: nonko(a)giti.waseda.ac.jp) if you are going to attend the meeting but not listed, or your name is not correctly represented, or there is anything wrong with your registration. Though the deadline for registration/hotel room reservation has passed, we are still maintaining the block reservation. We will return it to the hotel very shortly. If you are coming to Osaka, please advise us promptly. Please note that Japan is entering the "Golden Week" next Saturday. 4/29 Sat National Holiday (Green Day, former Showa Emperor's birthday) 4/30 Sun 5/01 Mon 5/02 Tue 5/03 Wed National Holiday (Constitution Day) 5/04 Thu National Holiday (simply holiday) 5/05 Fri National Holiday (Children Day) 5/06 Sat 5/07 Sun Many companies and organizations may not function during that week. Please take your immediate action for the registration. PS to Mr. Sullivan: Could you please post this message to the Q15 reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: remove
by Pearl Lai 24 Apr '00

24 Apr '00

Pearl Lai PM of GVC Corp. Tel: 886-3-3973690 #301 Fax: 886-3-3277062 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC numbers
by Sakae OKUBO 24 Apr '00

24 Apr '00

Dear Messrs Audet, Kumar, Anderson and Skran, The following APC numbers have been allocated to your contributions: APC-1777 Nortel Networks Treatment of information in locally generated messages in H.225.0 APC-1778 Nortel Networks Proposed clarifications to H.225.0v4 and H.323v4 for signalling tunnelling APC-1779 Nortel Networks Proposed clarifications to H.323 Annex M.1 APC-1780 Intel Authentication of the H.323 Mobile Terminal by the Visited Administrative Domain APC-1781 Lucent Technologies Reference Points for the Use of Annex G APC-1782 SONUS Networks Proposed Corrections to H.323 Annex E The current list of registered documents is attached. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0