February 2001 - sg16-avd - lists.packetizer.com

AW: Video codec for H.323 Annex I
by Baese Gero 22 Feb '01

22 Feb '01

Dear Mr. Li, experts, to repeat it again, we completely agree on the argumentation to use H.263 for the tests. It is incorporated in the simulation scenario since the very first version we provided last november. The one and only problem is the availability of appropriate software. In your email the question which software should be used is left open again. Thanks to Mr. Campos-Neto there is an excellent proposal if a third party can help us with bitstreams and a decoder executable. There are two other questions remaining open still. Is the test scenario document we provided accepted by both sides now ? Additionally we provided you with the draft of the joint document. Is this document accepted as well ? The deadline for submission is approaching. We really need to coincide for this topics to avoid long lasting discussions at the meeting. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Adam Li [mailto:adamli@icsl.ucla.edu] > Gesendet am: Mittwoch, 21. Februar 2001 10:17 > An: ITU-SG16(a)mailbag.cps.INTEL.COM; Baese Gero > Cc: John D. Villasenor; Tao Tian; Jay Fahlen; Yung Lyul Lee; So Youg > Kim; Jeong-Hoon Park; Paul E. Jones; Barry Aronson > Betreff: Video codec for H.323 Annex I > > Mr. Baese, experts, > > For evaluation of error protection schemes, it really make > sense to use > video codec that are mature and widely used instead of a > particular video > codec that is still early in development stage. > > The sole reason that there is a software implementation of > H.26L does not at > all make it a suitable criteria for selection of error > protection schemes. > The current development status of H.26L and its complexity > (which means it > is not likely to be used on mobile environment immediately > even after it is > finished) indicates that it is currently not the proper > platform to judge > the algorithms for Annex I - no matter it has an > implementation or not. > > Also, I would like to remind Mr. Baese that the the joint > discussion between > Q.13 and Q.15 on video codec issue has reached conclusion at > Geneva. Here I > quote the last paragraph of the related section from the > meeting report: > > "The Q.15 Rapporteur's final comment was that if you want to > do testing that > requires error resilience, then H.263 is the clear choice. > There needed to > be strong justification for using another codec." > > I hope there should be agreement on the testing codec soon. > > Regards, > > Adam Li > > > > ---------- > Adam H. Li > Image Communication Lab (310) 825-5178 (Lab) > University of California, Los Angeles (310) 825-7928 (Fax) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: AW: H.323 Annex I
by Baese Gero 22 Feb '01

22 Feb '01

Dear Mr. Li, experts, we are really happy to see some more people are interested in the Annex I discussion now. Unfortunately, at the moment the discussion is not focussing on the exact point. Without any doubt H.263 is stable and well documented. Our proposals intention was not(!) using H.26L instead of H.263. It was to find a practical solution to get useful results till the next meeting. Only H.26L software is officially available for both parties. Using proprietary H.263 software would lead to not comparable results. In other words, the basis for the decision of the group will be missing. We really aim at providing the group with what is necessary for the decision, therefore our proposal is to restrict ourselves to H.26L for practical reasons. > This topic has been discussed in the meeting last time > in Geneva. I think a conclusion has been reached then. > If Mr. Baese haven't read the study group meeting report, > I suggest you go ahead and read it. Hope we can get over > this soon, and focus on producing more solid results for > this meeting. A conclusion has been reached at the Geneva meeting and we don't think any misinterpretation is possible. Citation of the Geneva meeting report of Dale Skran: "The coders compared shall be H.263++ (the standard ITU-T code) and H.26L (as recommended by Q15)." There is no appropriate "standard ITU-T code" for H.263 available as we learned from Stephan Wenger. Using proprietary H.263 software is considered being unfair. Our proposals intention was to escape this quandary for the moment. By the time the H.263 software is available at the ITU-T we strongly support testing H.323 Annex I with it. Best Wishes Gero Baese PS: Mr. Li, are there open questions concerning the simulation scenario still or do you agree on that document ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 3

Launceston meeting
by OKUBO Sakae 22 Feb '01

22 Feb '01

Dear SG16 experts, We have obtained the final approval of the SG16 management to hold the Q. D,F,G,2-5/16 Launceston meeting during 5-9 March 2001. Mr. Christian Groves, meeting host, has advised us that the number of participants is 45 as of 21 February. Best regards, OKUBO Sakae *********************************************************** 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

H.248 protocol stack
by YouLing Sha 22 Feb '01

22 Feb '01

Hi, Can anyone help me to know the Megaco/H.248 protocol vendors available today? To implement Media Gateway, is there any differences between Megaco stack and H.248 stack? Thanks. Regards, YouLing Sha CyberPath Inc. (732) 463-7700 ext. 304 ysha(a)cyberpathinc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: a query
by Li, John 21 Feb '01

21 Feb '01

within the internet clouds, many protocols can be used to pass the signaling information, eg. SIP, H323 or even ISUP/TCP. Refer to SIP RFC or H323 spec. for details. thanks, John -----Original Message----- From: Alok Dubey (OCS-BLRAKS-AVS) [mailto:adubey@wipro.co.in] Sent: Wednesday, February 21, 2001 3:12 PM To: 'Li, John ' Cc: 'ITU-SG16(a)mailbag.cps.INTEL.COM' Subject: RE: a query hi, I agree it goes via SG to MGC..but that is when im going acros medias....POTS to VOIP etc.. but within the IP cloud.. how does the signalling take place.. eg from VOIP to VOIP.. lets say i have 1 MGC (or u can assume this to be an IP phone too) A and another ip phone B in a diff LAN seg ( or a POTs phone attachd to a different gateway...) now when i call from A( if its an MGC ill use A as a gateway) to B , A uses the gatekeeper/callmanager to get the number (ARQ) and then depending on the mode of call.. . it sets up the call from A to B by either going via the gateway or by seting up the session directly.. now this part of the signalling is what i am interested in.. is it ordinary TCP/IP with some good old ports or is it RTP too? if it isnt.. as u put it .. how do i make my network elements mark/identify and prioritise this traffic. will i have to do it at the ingress node.ie when it enters the network? and what is the content of the packet? ..is it well defined? Rgds Alok -----Original Message----- From: Li, John To: 'Alok Dubey (OCS-BLRAKS-AVS)' Sent: 2/22/01 1:08 AM Subject: RE: a query Alok, The call control messages (including setup) usually goes thru the signaling path via SG and MGC. RTP is used for the media tranfer. Hope it helps. John -----Original Message----- From: Alok Dubey (OCS-BLRAKS-AVS) [mailto:adubey@WIPRO.CO.IN] Sent: Wednesday, February 21, 2001 2:13 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: a query hi im sorry for posing this query out here but i needed this answer asap.. Im basically more of an implementor than a protocol developer and all my job is above the layer 3.. ie socket programming etc. Right now while going thru the specs, I could not find any reasonable explanation on how u prioritise traffic for call setup? for eg are u sending callsetup info over RTP ports too..? if yes, i still have to figure out how to use Voice Activity Detection to conserve bandwidth a feature which lets us drop voice packets below a certain db level .., if no this basically means that setting up a call could take a long time and the traffic associated with it cannot be controlled/prioritised.. can anyone refer me to any good specs Sorry to be wasting ur time on such a query.. but i couldnt think of a better place to pose this question. Rgds Alok ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: a query
by Alok Dubey (OCS-BLRAKS-AVS) 21 Feb '01

21 Feb '01

hi, I agree it goes via SG to MGC..but that is when im going acros medias....POTS to VOIP etc.. but within the IP cloud.. how does the signalling take place.. eg from VOIP to VOIP.. lets say i have 1 MGC (or u can assume this to be an IP phone too) A and another ip phone B in a diff LAN seg ( or a POTs phone attachd to a different gateway...) now when i call from A( if its an MGC ill use A as a gateway) to B , A uses the gatekeeper/callmanager to get the number (ARQ) and then depending on the mode of call.. . it sets up the call from A to B by either going via the gateway or by seting up the session directly.. now this part of the signalling is what i am interested in.. is it ordinary TCP/IP with some good old ports or is it RTP too? if it isnt.. as u put it .. how do i make my network elements mark/identify and prioritise this traffic. will i have to do it at the ingress node.ie when it enters the network? and what is the content of the packet? ..is it well defined? Rgds Alok -----Original Message----- From: Li, John To: 'Alok Dubey (OCS-BLRAKS-AVS)' Sent: 2/22/01 1:08 AM Subject: RE: a query Alok, The call control messages (including setup) usually goes thru the signaling path via SG and MGC. RTP is used for the media tranfer. Hope it helps. John -----Original Message----- From: Alok Dubey (OCS-BLRAKS-AVS) [mailto:adubey@WIPRO.CO.IN] Sent: Wednesday, February 21, 2001 2:13 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: a query hi im sorry for posing this query out here but i needed this answer asap.. Im basically more of an implementor than a protocol developer and all my job is above the layer 3.. ie socket programming etc. Right now while going thru the specs, I could not find any reasonable explanation on how u prioritise traffic for call setup? for eg are u sending callsetup info over RTP ports too..? if yes, i still have to figure out how to use Voice Activity Detection to conserve bandwidth a feature which lets us drop voice packets below a certain db level .., if no this basically means that setting up a call could take a long time and the traffic associated with it cannot be controlled/prioritised.. can anyone refer me to any good specs Sorry to be wasting ur time on such a query.. but i couldnt think of a better place to pose this question. Rgds Alok ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

H.225.0 Annex G
by Douglas Clowes 21 Feb '01

21 Feb '01

Has anybody implemented Inter-domain communication = what is the state of implementation of this recommendation? Is anybody using it (has it deployed)? TIA, Douglas ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Anybody using GSM HR or EFR codecs?
by Douglas Clowes 21 Feb '01

21 Feb '01

Anybody at all? If so, what RTP payload types do you use and how do you signal the RTP payload type in the Fast Start, OLC and/or OLCACK? Douglas At 06:56 20/02/2001 +1100, Douglas Clowes wrote: >Could some kind soul please point me to the definitive guide to the use of >RTP dynamic payload types in H.245. I've looked and can't seem to find any >adequate coverage. > >If anybody has firm ideas how it's done, I would be pleased to receive the >benefit of their knowledge. > >The documentation talks about the use of dynamic payload types in the use >of alternative packetisation for video, but there seems to be a need for >dynamic payload types in audio codecs which have H.245 code points, but not >RTP static payload types (such as GSM HR and EFR). > >Dynamic payload types are being used for mode specification in SDP as well, >with some MGs using them to specify the desired rate for G.723.1 (High or >Low). > >IMHO, the standard needs to be expanded on the use of dynamic paylaod >types, with particular reference to interworking with SDP based MGs and SIP. > >Cheers, > >Douglas Clowes > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >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

AW: Video codec for H.323 Annex I
by Baese Gero 21 Feb '01

21 Feb '01

Dear Mr. Campos-Neto, experts, thank you very much Mr. Campos-Neto for this excellent proposal. Hopefully there will be a third party providing the bitstreams and an decoder executable for the tests. The deadline to submit the documents is on the 26t of February. If there is a third party willing to help us out please react quickly. Otherwise we will have to use our own implementations leading to not comparable results. In this special case, perhaps the group can accept us providing the document containing the results of the tests later than monday 26t ? Best Wishes Gero Baese PS: Needed are H.263 Profile 3 and 4 Level 20. v. APC-1993r2 > -----Ursprüngliche Nachricht----- > Von: Simao Campos-Neto [mailto:simao.campos@labs.comsat.com] > Gesendet am: Mittwoch, 21. Februar 2001 11:20 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Video codec for H.323 Annex I > > Just a thought: > > would it be possible to use a common implementation of > H.263+, e.g. by a third-party company that could volunteer to > provide encoded streams for parties implementing the H.323-I > simulations and decoding transmission-disturbed bitstreams > provided back to it? This would circumvent the unavailability > of a common, publicly available H.263 implementation and > provide that the same H.263 implementation is used by all parties. > > Another option would be that one company provides e.g. an > executable version of H.263 (under a specific NDA for this > particular purpose) to the parties simulating H.323-I. This > would accomplish the same purpose. > > All in support of a good spirit of cooperation! > > Best regards, > Simao > > -- > ============================================================== > ============= > Simao Ferraz de Campos Neto, Scientist *All comments are > strictly my own* > LMGT/COMSAT Laboratories Tel: +1-301-428-4516 > 22300 Comsat Drive Fax: +1-301-428-9287 > Clarksburg MD 20871 - USA E-mail: > simao.campos(a)labs.comsat.com > ============================================================== > ============= > ******** Practice random kindness and senseless acts of > beauty ******** > ============================================================== > ============= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Usage of H.248 in ServiceControlDescriptor
by Paul, Manoj 20 Feb '01

20 Feb '01

With reference to H.323 Annex K, ServiceControlDescriptor has following ASN.1 syntax: ServiceControlDescriptor ::= CHOICE { url IA5String (SIZE(0..512)), -- indicates a URL-referenced -- protocol/resource signal H248SignalsDescriptor, nonStandard NonStandardParameter, callCreditServiceControl CallCreditServiceControl, ... } The use of "url" part is very well described in Annex K but I could not find the use of H248SignalDescriptor in any of the H.323 Annex K documents. I believe the reason for this codepoint is to use H.248 functionality in controlling supplementary Services at the endpoints, but isn't that what H.323 Annex L tries to achieve using Stimulus Control Protocol (Which is also H.248 based). Are we trying to achieve the same function by using this codepoint in Annex K. I shall appreciate if someone could clarify the use of H.248SignalDescriptor in ServiceControl Descriptor structure. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0