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

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 27 Apr '00

27 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