- sg16-avd - lists.packetizer.com

APC number allocation
by Sakae OKUBO 04 May '00

04 May '00

Dear P Luthi, T Anderson, D Walker, A Nehru, S Terrill, The following APC numbers have been allocated to your contributions: APC-1829 PictureTel Corp Proposed changes to H.246 to support H.243 commands MVC, MVA, and MVR APC-1830 Lucent Technologies Architectures for H.323 Robustness APC-1831 Editor (D Walker) Draft White Paper H.323 Annex L Stimulus Protocol APC-1832 SS8 Networks H.225.0 IRR Enhancements for Large Scale Operation APC-1833 SS8 Networks Changes to H.323 Alternate Gatekeeper Procedures APC-1834 SS8 Networks Additions to the H.323 Implementor's Guide APC-1835 Trillium Digital Systems Adding mechanisms in H.323 to ensure synchronisation of call states between endpoints for robustness APC-1836 Ericsson Service execution within H.323 mobility The updated list of registered contributions is available as: http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000505.html http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000505.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

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

04 May '00

Dear Mr. Holm, >I am going to participate in the meeting. Due to a crashed PC I have lost >all information about registration, hotels etc. The meeting notice and the registration form are available at: http://standard.pictel.com/ftp/avc-site/0005_Osa/Notice_ITU-T_Osaka.txt and http://standard.pictel.com/ftp/avc-site/0005_Osa/Info_ITU-T_Osaka_r1.zip If you have any problem to retrieve them, please advise me. Please send your hotel room requirement to Ms. Noriko Hosokawa (e-mail: nonko(a)giti.waseda.ac.jp, FAX&TEL: + 81-3-5286-9863) at the earliest occasion. >Further more I need to make an editors contribution on Annex M.2. APC-1828 has been allocated to your "Draft H.323 Annex M.2". 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 *********************************************************** >Can you send me (or guide me how to get them) the necessary documents and na >APC number. > >/Regards Jan Holm > Ericsson Telecom AB > +46 70 519 7378 > >Sakae OKUBO wrote: > >> 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

upload of APC-1781
by Terry L Anderson 04 May '00

04 May '00

APC-1781 - Reference Points for the use of Annex G has been uploaded as APC-1781.zip -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

upload of apc-1823
by Bob Gilman 04 May '00

04 May '00

APC-1823 - Faster Capability Negotiation and Repeated Fast Connect Procedures has been uploaded as apc-1823.zip -Bob ---------------------------------------------------- Bob Gilman rrg(a)lucent.com (303)538-3868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Robustness
by Archana Nehru 04 May '00

04 May '00

hi all, This is following our discussion in the last teleconference. In the last discussion we wanted answers to the following questions: a) do we need "call-state synchronisation" between the two legs of a call when an intermediate GK fails? Is it ok to assume that things will sort themselves out without any significant loss? b) Are there any cases where absence of "call-synchronisation" procedures can lead to hung resources or call-release if any) of a stable call? c) Are there any other issues(e.g: degraded service) that we need to take care of in the absence of "call-synchronisation"? d) if the answer to b)is yes, then do we need an ACK at the H.323 layer if H.323 layer runs over SCTP/DDP? After the teleconference, we went back to do some study and discussions with Randy and Qiaobing and here is a summary of that: a) While SCTP/DDP provides fault tolerance at the transport layer, it cannot handle the case where a GK fails after the message is ACKed at the SCTP layer of the GK. So in a case like: (CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) -----SCTP-ACK---> (GK NODE FAILS) when EP1 sends a RELCOMPLETE message to the GK, the SCTP/DDP sends an SCTP-ACK to the EP1 and if the GK node fails after this step, then the RELCOMPLETE message is lost. SCTP/DDP layer cannot detect such failures and therefore it is upto the H.323 protocol layer to recover from it (if required). So, we agreed that messages at the GK can get lost even with SCTP/DDP. Please note that it implies that in a normal GK implementation, the H.323 layer will probably use a "queue" to exchange messages with the SCTP/DDP layer. The SCTP/DDP will put all those messages in this "queue" for which it has sent an SCTP-ACK. Therefore when the H.323 layer fails, we lose all the messages that were present in the "queue" and these messages may belong to multiple calls. In other words, failure of the H.323 layer is not trivial, since it doesnot mean loss of just one message belonging to that "one particular call" that was being processed at the time of the failure. It means the loss of all those messages that were present in the "queue" at the time of the failure which may belong to multiple calls. Having said this, we wanted to identify the impact of the lost messages at the GK and at the endpoints. I am enclosing a table of some of the possible messages that can be lost and what they might potentially translate to. please note that this tabel is not exhaustive . As of now, the current H.323 specs does not talk about the action that should be taken if for a particular command/indication, the terminal doesnot respond as desired. I guess the assumption is that the message is delivered reliably. <<CallStateSync.doc>> We would like to discuss the issues listed in the tables with the group to get an idea of how current implementations behave if these messages are lost. Depending on the general consensus, we can conclude whether or not an ACK should be introduced. Regards Archana

3 2

APC number allocation
by Reddy, Paul K 04 May '00

04 May '00

Dear P Jones, J Sundquist, G Freundlich, V Kumar, M Buckley, Bob Gilman, Jill Caugherty, P Reddy, In response to your requests, APC numbers have been allocated as attached. The updated list of registered contributions is available as: http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000504.html http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000504.doc The mark X at LA (Late Arrival) will be removed if the contribution is uploaded on time. 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 *********************************************************** 1815 Cisco Systems Indicating Support of Annex E for Alternate Endpoints 1816 Editor (J Sundquist) Draft H.323 Annex H (User, Terminal and Service Mobility) 1817 Q21/15 Liaison to ITU-T SG12 on method for deciding on codec type and packet size 1818 Intel Credit query and call cut-off 1819 Lucent Technologies Update on ETSI TIPHON architecture work including latest TIPHON Architecture Draft 1820 Lucent Technologies Update on ETSI TIPHON QoS work including latest TIPHON End to End QoS Framework Draft 1821 Editor (M Buckley) Latest draft of Annex N of H.323 1822 Lucent Technologies Generic Bearer Descriptor for End to End QoS 1823 Nortel, Lucent Repeated Fast Connect Procedures with Repeated fastStart 1824 Cisco Systems Addition of AnnexECallSignallingAddress field to RRQ, LCF messages 1825 Cisco Systems Clarification of use of h245Tunneling flag in Call Proceeding 1826 Intel Addition of Service Control and Service Data Functions into H.323 Mobility network Architecture 1827 Intel Mobility State Models for H.323 Annex H work ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

None
by Archana Nehru 03 May '00

03 May '00

hi all, This is following our discussion in the last teleconference. In the last discussion we wanted answers to the following questions: a) do we need "call-state synchronisation" between the two legs of a call when an intermediate GK fails? Is it ok to assume that things will sort themselves out without any significant loss? b) Are there any cases where absence of "call-synchronisation" procedures can lead to hung resources or call-release if any) of a stable call? c) Are there any other issues(e.g: degraded service) that we need to take care of in the absence of "call-synchronisation"? d) if the answer to b)is yes, then do we need an ACK at the H.323 layer if H.323 layer runs over SCTP/DDP? After the teleconference, we went back to do some study and discussions with Randy and Qiaobing and here is a summary of that: a) While SCTP/DDP provides fault tolerance at the transport layer, it cannot handle the case where a GK fails after the message is ACKed at the SCTP layer of the GK. So in a case like: (CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP) -----SCTP-ACK---> (GK NODE FAILS) when EP1 sends a RELCOMPLETE message to the GK, the SCTP/DDP sends an SCTP-ACK to the EP1 and if the GK node fails after this step, then the RELCOMPLETE message is lost. SCTP/DDP layer cannot detect such failures and therefore it is upto the H.323 protocol layer to recover from it (if required). So, we agreed that messages at the GK can get lost even with SCTP/DDP. Please note that it implies that in a normal GK implementation, the H.323 layer will probably use a "queue" to exchange messages with the SCTP/DDP layer. The SCTP/DDP will put all those messages in this "queue" for which it has sent an SCTP-ACK. Therefore when the H.323 layer fails, we lose all the messages that were present in the "queue" and these messages may belong to multiple calls. In other words, failure of the H.323 layer is not trivial, since it doesnot mean loss of just one message belonging to that "one particular call" that was being processed at the time of the failure. It means the loss of all those messages that were present in the "queue" at the time of the failure which may belong to multiple calls. Having said this, we wanted to identify the impact of the lost messages at the GK and at the endpoints. I am enclosing a table of some of the possible messages that can be lost and what they might potentially translate to. please note that this tabel is not exhaustive . As of now, the current H.323 specs does not talk about the action that should be taken if for a particular command/indication, the terminal doesnot respond as desired. I guess the assumption is that the message is delivered reliably. <<CallStateSync.doc>> We would like to discuss the issues listed in the tables with the group to get an idea of how current implementations behave if these messages are lost. Depending on the general consensus, we can conclude whether or not an ACK should be introduced. Regards Archana

1 0

Re: APC number request
by Reddy, Paul K 03 May '00

03 May '00

Dear Mr. Okubo, Please allocate me two more APC numbers for the following documents for H.323 Annex H work. Document1 Title: Addition of Service Control and Service Data Functions into H.323 Mobility network Architecture Document2 Title: Mobility State Models for H.323 Annex H work thanks a lot, Paul Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Wednesday, May 03, 2000 5:27 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: APC number request Dear Mr. Okubo, Could you allocate me an APC number for: Draft H.323 Annex H (User, Terminal and Service Mobility). Thanks in advance. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.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: Current RTP-MIB definition precludes multi-unicast RTP sessio n?
by Strahm, Bill 03 May '00

03 May '00

I think you are going a little overboard on your definition of "One Session" First off I do not see how you could have a third party monitor setup to catch all of the unicast streams involved. Third party monitors were designed to handle multicast cases where you can setup the monitor to receive the multicast address/port combination that is needed to get the management data. I do not believe that your multi-unicast session is held up in the RTP Spec >From RFC 1889 Sec 3 Definitions RTP session: The association among a set of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network addresses plus a common port pair. In a multimedia session, each medium is carried in a separate RTP session with its own RTCP packets. The multiple RTP sessions are distinguished by different port number pairs and/or different multicast addresses. >From this reading each of the A->B A->C is a seperate RTP Session ( there are different destination transport address pairs). If you want to define a seperate definition of an RTP session as Where one endpoint unicasts the same information to multiple destination addresses on the same port, I do not see this definition supported by the RTP spec, and I do not see how this can work because B and C will not see each others RTCP packets to create a single session to be managed. Bill > -----Original Message----- > From: Tim Chen [mailto:scc@trillium.com] > Sent: Wednesday, May 03, 2000 9:45 AM > To: 'Strahm, Bill'; 'rem-conf(a)es.net'; ITU-SG16(a)mailbag.cps.intel.com > Cc: Michael Bird > Subject: RE: Current RTP-MIB definition precludes multi-unicast RTP > sessio n? > > > Bill, > > Thank you for your reply. However, I am not > convinced that multi-unicast RTP session MIB is > properly handled in the current RTP MIB draft. > Please find my comments below. > > > I see each one of these as seperate channels, with > different feedback > > streams. Therefor participant A would have a RtpSessionEntry > > for A->B and > > A->C, participant B would have B->A and B->C etc. Yes this > > doesn't scale > > very well as you add many participants, but then neither > does sending > > multiple copies of the same stream, so I think it is a wash. > > > > To clarify. The RtpReceiverEntry needs to have the feedback > > for just ONE > > receiver anyway, so why not model it as multiple unicast > > flows (since that > > is indeed what we have here) > > > > I do not see a problem > > The issue I am raising is that we are dividing up what is truly > a single RTP session as defined in RFC 1889 with multiple RTP > sessions > in MIB. The RTP MIB draft has changed the definition of a > RTP session. > > Let's say if I want to implement a monitor for the above > example where A is sending to both B and C in a RTP session. > I send a MIB request for a RTP session and according to the > current MIB specs, I will be getting back only a single stream > in the RTP session (say A->B). I cannot be certain if > another stream (A->C) exists for this RTP session > unless I dump the whole MIB and try to correlate all the > "MIB RTP session" with the local address of A. Third party monitors were not designed for Unicast applications. How do you expect to get the Unicast RTCP information to this third party monitor somewhere else in the network ??? > In addition, the reverse sender table mapping is non unique. > Let's continue with the above example and look at the > sender A. Sender A's send address is common to the stream > A->B and A->C. Then using sender A's rtpSessionDomain and > rtpSenderAddr, > I can map to the session index corresponding either to the > (A->B) stream > or the session index corresponding to the (A->C) stream. This > is contradictory to the statement in the MIB rtpSenderInverseEntry > that "Each entry corresponds to exactly one entry in the > rtpSenderTable - the entry containing the index pair, > rtpSessionIndex, rtpSenderSSRC". > Again I say that the A->B stream is seperate than the A->C stream. Looking at endpoint A we have a table that has two entries in the RtpSessionEntry one for each stream, and we have uniqueness. From B we have one entry in the RtpSessionEntry table (for the A->B stream) and no knowledge of the A->C stream (we can't see it so we can't manage it from here). The same thing applies for C. > The MIB draft should specify clearly how the multi-unicast > RTP session scenario should be handled and clarify some > of these inconsistencies. > > Regards, > Tim Chen > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Current RTP-MIB definition precludes multi-unicast RTP sessio n?
by Tim Chen 03 May '00

03 May '00

Bill, Thank you for your reply. However, I am not convinced that multi-unicast RTP session MIB is properly handled in the current RTP MIB draft. Please find my comments below. > I see each one of these as seperate channels, with different feedback > streams. Therefor participant A would have a RtpSessionEntry > for A->B and > A->C, participant B would have B->A and B->C etc. Yes this > doesn't scale > very well as you add many participants, but then neither does sending > multiple copies of the same stream, so I think it is a wash. > > To clarify. The RtpReceiverEntry needs to have the feedback > for just ONE > receiver anyway, so why not model it as multiple unicast > flows (since that > is indeed what we have here) > > I do not see a problem The issue I am raising is that we are dividing up what is truly a single RTP session as defined in RFC 1889 with multiple RTP sessions in MIB. The RTP MIB draft has changed the definition of a RTP session. Let's say if I want to implement a monitor for the above example where A is sending to both B and C in a RTP session. I send a MIB request for a RTP session and according to the current MIB specs, I will be getting back only a single stream in the RTP session (say A->B). I cannot be certain if another stream (A->C) exists for this RTP session unless I dump the whole MIB and try to correlate all the "MIB RTP session" with the local address of A. In addition, the reverse sender table mapping is non unique. Let's continue with the above example and look at the sender A. Sender A's send address is common to the stream A->B and A->C. Then using sender A's rtpSessionDomain and rtpSenderAddr, I can map to the session index corresponding either to the (A->B) stream or the session index corresponding to the (A->C) stream. This is contradictory to the statement in the MIB rtpSenderInverseEntry that "Each entry corresponds to exactly one entry in the rtpSenderTable - the entry containing the index pair, rtpSessionIndex, rtpSenderSSRC". The MIB draft should specify clearly how the multi-unicast RTP session scenario should be handled and clarify some of these inconsistencies. Regards, Tim Chen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0