- sg16-avd - lists.packetizer.com

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