- sg16-avd - lists.packetizer.com

APC 1774 uploaded
by Amit sahai 05 May '00

05 May '00

Hi all , APC - 1774 has been uploaded on avc/incoming site . regards, Amit Sahai, Silicon Automation Systems . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [apc] Re: Request for 2 APC numbers for the Osaka Rapporteurs meeting
by Euchner Martin 05 May '00

05 May '00

I've uploaded APC-1753 and APC-1754 as zipped files to the Incoming directory. APC-1753.zip >"White Paper H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES >(H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS" is a zip file that contains the following parts: APC-1753 h235v2changes.doc: contribution with the summary of changes Draft_H0235Ev2r3_CM.doc: the white paper with change marks as WORD97 document Draft_H0235Ev2r3_CM.pdf: the same change marked but as PDF document Draft_H0235Ev2r3_NCM.doc: the white paper without change marks as WORD97 document Draft_H0235Ev2r3_NCM.pdf: the same as PDF document APC-1754.zip ">"White Paper H.323 Annex J - Security for H.323 Annex F" is a zip file that contains the following parts: APC-1754 H323AnnexJ.doc: the contribution with the summary of changes Draft_H323AnnexJr3.doc: the white paper as WORD97 document Draft_H323AnnexJr3.pdf: the white paper as PDF document Kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Sakae OKUBO [SMTP:sokubo@MN.WASEDA.AC.JP] Sent: Tuesday, April 11, 2000 12:39 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: [apc] Re: Request for 2 APC numbers for the Osaka Rapporteurs meeting Dear Mr. Euchner, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1753 >"White Paper H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES >(H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS" APC-1754 >"White Paper H.323 Annex J - Security for H.323 Annex F" 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

APCs uploaded
by Klaghofer Karl ICN SIB NL D1 05 May '00

05 May '00

APCs 1759 - 1764 have been uploaded to the pictel\incoming site. Regards, Karl Klaghofer, Siemens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: RFC 2793 on RTP Payload for Text Conversation
by Gunnar Hellstrom 05 May '00

05 May '00

IP video telephony with text component, IP Text Telephony, IP Total Conversation, IP Mobiles with text etc. can now be accomplished in a standardised way. The specification on how to transmit text for real time chatting in IP networks is now published as RFC 2793 from IETF. (It was approved in February, but got published with its number now.) With it comes a new registered MIME type "text/t140" so that it can be specified for example in the multimedia protocol SIP. The multimedia protocol ITU-T H.323 is already ready for text addition with its Annex G, referencing to RFC 2793. Thanks to all who have contributed, and good luck to all who now creates interworking Total Conversation solutions with this component! Regards Gunnar Hellström ______________________________________ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm Sweden Mob +46 708 204 288 Tel +46 8 556 002 03 Fax +46 8 556 002 06 Video +46 8 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.omnitor.se -----Original Message----- From: RFC Editor [mailto:rfc-ed@ISI.EDU] Sent: Friday, May 05, 2000 1:17 AM To: IETF-Announce: ; Cc: rfc-ed(a)ISI.EDU; rem-conf(a)es.net Subject: RFC 2793 on RTP Payload for Text Conversation A new Request for Comments is now available in online RFC libraries. RFC 2793 Title: RTP Payload for Text Conversation Author(s): G. Hellstrom Status: Standards Track Date: May 2000 Mailbox: gunnar.hellstrom(a)omnitor.se Pages: 10 Characters: 20674 Updates/Obsoletes/SeeAlso: None URL: ftp://ftp.isi.edu/in-notes/rfc2793.txt This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. RETRIEVE: rfc DOC-ID: rfc2793

1 0

Re: Contribution number request
by Sakae OKUBO 05 May '00

05 May '00

Dear Mr. Aronson, >Could you please allocate APC numbers for three Toshiba contributions to >the upcoming Osaka meeting: APC-1838 >"H.323 Annex I Terms of Reference" APC-1839 >"Draft H.323 Annex I" APC-1840 >"Proposal for Mobile IP in H.323 Annex I" I wonder if the first two are from Editor. Please advise me if that is the case. 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 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

Re: Current RTP-MIB definition precludes multi-unicast RTP sessio n?
by Strahm, Bill 03 May '00

03 May '00

My comments inline ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Tim Chen [mailto:scc@trillium.com] > Sent: Tuesday, May 02, 2000 5:19 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Cc: 'mbaugher(a)passedge.com'; 'bill.strahm(a)intel.com'; > 'irina(a)ennovatenetworks.com'; Michael Bird > Subject: Current RTP-MIB definition precludes multi-unicast > RTP session? > > > Hello, > > I see a problem with current "RTP session" definition in RTP MIB > <draft-ietf-avt-rtp-mib-09.txt>. > This MIB definition precludes multi-unicast RTP session which > is clearly > permissible under section 3 of RFC 1889: > > 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. > > Hence each participant in an RTP session could have > a different RTP receive address. The only requirement > from the specs is that the RTP and RTCP port pair used by all > participants > has to be the same. For example, I can have the following > RTP session with three participants, each receiving RTP packets > on a different IP address: > > participant A : receive RTP on 103.403.25.45 port 6000 > participant B : receive RTP on 103.403.33.34 port 6000 > participant C : receive RTP on 103.403.25.98 port 6000 > > So for participant A, he will send to two remote addresses: > 103.403.33.34:6000 (that B listens to) and 103.403.25.98:6000 > (that C listens to). > > However, the current RTP session MIB draft (page 10) has the > following structure: > > RtpSessionEntry ::= SEQUENCE { > rtpSessionIndex Integer32, > rtpSessionDomain TDomain, > rtpSessionRemAddr TAddress, > rtpSessionLocAddr TAddress, > rtpSessionIfIndex InterfaceIndex, > rtpSessionSenderJoins Counter32, > rtpSessionReceiverJoins Counter32, > rtpSessionByes Counter32, > rtpSessionStartTime TimeStamp, > rtpSessionMonitor TruthValue, > rtpSessionRowStatus RowStatus > } > > This definition allows only a single remote address. This > is contradictory to RFC 1889 which clearly permits > multiple remote addresses in a single RTP session. > > Will the authors of this MIB give some clarification? Thanks. > 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 Bill Strahm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1796 and APC-1797
by Michael Fortinsky 03 May '00

03 May '00

Dear Mr. Okubo, I have posted the following documents to the PictureTel ftp site (standard.pictel.com) avc-site/Incoming/APC-1796.zip H.225.0 Annex G version 1 with corrections avc-site/Incoming/APC-1797.zip H.225.0 Annex G version 2 draft Please upload them into the 0005_Osa directory. Thank you. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: a liaison for SG9
by Michael Fortinsky 03 May '00

03 May '00

Gunnar, I want to point out a correction that needs to be made to your document. In the next to last paragraph: "H.323 Annex H - Secure SET, which defines a simple profile of H.235." should read "H.323 Annex J - Secure SET, which defines a simple profile of H.235." (ie, should be Annex J) Mike Gunnar Hellstrom <gunnar.hellstrom(a)OMNITOR.SE> on 05/03/2000 01:22:25 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Michael Fortinsky) Subject: Re: a liaison for SG9 Dear Sakae OKUBO, A good initiative! I corrected a mistake with the title of H.323 Annex G, and added a few words. The document with proposed changemarks is included. Regards Gunnar ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Sakae OKUBO Sent: Wednesday, May 03, 2000 5:42 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: a liaison for SG9 Dear Glen, >SG9 is working some cable TV issues, and part of their focus seems to be >to support telephony and general network services over the cable >infrastructure. At the May SG9 meeting, they will be reviewing >contributions related to signaling for IP telephony and I believe the >work we've done in Q.13 and Q.14 is relevant. > >I've attached a draft liaison describing some of our work (with Dale's >help). Do you think we should review this at the Osaka meeting, which >happens to be the same week SG9 meets? I plan to send this off to Mr. >Bigi in the next day or so. This document has been given APC-1812 and is available at: ftp://standard.pictel.com/avc-site/0005_Osa/APC-1812.zip or http://standard.pictel.com/ftp/avc-site/0005_Osa/APC-1812.zip 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

APC number request
by Jaakko Sundquist 03 May '00

03 May '00

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

1 0

Re: a liaison for SG9
by Sakae OKUBO 03 May '00

03 May '00

Dear Glen, >SG9 is working some cable TV issues, and part of their focus seems to be >to support telephony and general network services over the cable >infrastructure. At the May SG9 meeting, they will be reviewing >contributions related to signaling for IP telephony and I believe the >work we've done in Q.13 and Q.14 is relevant. > >I've attached a draft liaison describing some of our work (with Dale's >help). Do you think we should review this at the Osaka meeting, which >happens to be the same week SG9 meets? I plan to send this off to Mr. >Bigi in the next day or so. This document has been given APC-1812 and is available at: ftp://standard.pictel.com/avc-site/0005_Osa/APC-1812.zip or http://standard.pictel.com/ftp/avc-site/0005_Osa/APC-1812.zip 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

2 1

Welcome to tsg16q12
by Mailserv＠itu.int 03 May '00

03 May '00

-- Welcome to the tsg16q12 mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to <Mailserv(a)itu.int> with the following command in the body of your email message: unsubscribe tsg16q12 or from another account, besides ITU-SG16(a)MAILBAG.INTEL.COM: unsubscribe tsg16q12 ITU-SG16(a)MAILBAG.INTEL.COM If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to <owner-tsg16q12(a)itu.int> . This is the general rule for most mailing lists when you need to contact a human. #### No info available for tsg16q12. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Welcome to tsg16q13
by Mailserv＠itu.int 03 May '00

03 May '00

-- Welcome to the tsg16q13 mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to <Mailserv(a)itu.int> with the following command in the body of your email message: unsubscribe tsg16q13 or from another account, besides ITU-SG16(a)MAILBAG.INTEL.COM: unsubscribe tsg16q13 ITU-SG16(a)MAILBAG.INTEL.COM If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to <owner-tsg16q13(a)itu.int> . This is the general rule for most mailing lists when you need to contact a human. #### No info available for tsg16q13. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Welcome to tsg16q14
by Mailserv＠itu.int 03 May '00

03 May '00

-- Welcome to the tsg16q14 mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to <Mailserv(a)itu.int> with the following command in the body of your email message: unsubscribe tsg16q14 or from another account, besides ITU-SG16(a)MAILBAG.INTEL.COM: unsubscribe tsg16q14 ITU-SG16(a)MAILBAG.INTEL.COM If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to <owner-tsg16q14(a)itu.int> . This is the general rule for most mailing lists when you need to contact a human. #### No info available for tsg16q14. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Contribution number request
by Sakae OKUBO 02 May '00

02 May '00

Dear Jill Caugherty, Dear Francois Audet, The following APC number has been allocated to your contribution: 1813 Cisco Clarification of useAnnexECallSignalling flag in ACF message 1814 Nortel Networks Use of nonStandardControl field in H.323 Annex M.1 The updated list of registered contributions is available as: http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000503.html http://standard.pictel.com/ftp/avc-site/0005_Osa/0005_Osa_000503.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

Current RTP-MIB definition precludes multi-unicast RTP session?
by Tim Chen 02 May '00

02 May '00

Hello, I see a problem with current "RTP session" definition in RTP MIB <draft-ietf-avt-rtp-mib-09.txt>. This MIB definition precludes multi-unicast RTP session which is clearly permissible under section 3 of RFC 1889: 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. Hence each participant in an RTP session could have a different RTP receive address. The only requirement from the specs is that the RTP and RTCP port pair used by all participants has to be the same. For example, I can have the following RTP session with three participants, each receiving RTP packets on a different IP address: participant A : receive RTP on 103.403.25.45 port 6000 participant B : receive RTP on 103.403.33.34 port 6000 participant C : receive RTP on 103.403.25.98 port 6000 So for participant A, he will send to two remote addresses: 103.403.33.34:6000 (that B listens to) and 103.403.25.98:6000 (that C listens to). However, the current RTP session MIB draft (page 10) has the following structure: RtpSessionEntry ::= SEQUENCE { rtpSessionIndex Integer32, rtpSessionDomain TDomain, rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus } This definition allows only a single remote address. This is contradictory to RFC 1889 which clearly permits multiple remote addresses in a single RTP session. Will the authors of this MIB give some clarification? Thanks. Regards, Tim Chen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0