- sg16-avd - lists.packetizer.com

Q.G: AVD-2046 uploaded
by Euchner Martin 23 Feb '01

23 Feb '01

Please find AVD-2046.zip (Workplan for Question "Security of Multimedia Systems and Services") uploaded to the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/ <ftp://standard.pictel.com/avc-site/Incoming/> The file will be moved to ftp://standard.pictel.com/avc-site/0103_Lau/ <ftp://standard.pictel.com/avc-site/0103_Lau/> in a while. Note: AVD-2046 (without zip) has possibly been corrupted during upload. You can safely ignore that fragment. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2080 uploaded
by Klaghofer Karl ICN EN HC SE 81 23 Feb '01

23 Feb '01

Dear all, I have uploaded AVD-2080 (Liaison from ECMA TC32, Title: "Draft ECMA Standard on basic call interworking between H.323 and QSIG") to the "Incoming" directory. Thanks. Karl Klaghofer, Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 23 Feb '01

23 Feb '01

Dear Mr. Li, experts, we provided you with the draft of the technical comparison document. A lot of time elapsed and now you don't consider it realistic anymore to do this joint work. We regret your resistance. The consequence would be wasting the time of the group at the meeting with what we were supposed to do in advance. Please reconsider your answer and the time delay caused by you with it. The document attached to your last email by mistake I guess was an old collection of values. The more comprehensive test scenario document is APC-1993r2, attached to this email. It will be provided as document AVD-2059 at the next meeting. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Adam Li [mailto:adamli@icsl.ucla.edu] > Gesendet am: Donnerstag, 22. Februar 2001 11:55 > An: Baese Gero; ITU-SG16(a)mailbag.cps.INTEL.COM > Cc: Tao Tian; Jay Fahlen; John D. Villasenor; Barry Aronson; Paul E. > Jones; Jeong-Hoon Park; So Youg Kim; Yung Lyul Lee > Betreff: RE: Video codec for H.323 Annex I > > Mr. Baese, experts, > > For the testing condition document, I believe we have settled > on most of the > issues. So here is the testing document, and please take a > look and let me > know if there is anything else that we need to discuss. > > About the feature comparison document, I suggest that we both draft > documents for the point to point comparisons with the > technical reasoning. > From the current schedule situation, it seems that it is more > realistic for > us to submit two independent documents. We can go over them > at the meeting, > and combine them then if necessary. > > Regards, > > Adam > > > > ---------- > Adam H. Li > Image Communication Lab (310) 825-5178 (Lab) > University of California, Los Angeles (310) 825-7928 (Fax) >

2 1

Registering documents for the upcoming ITU-T meeting
by Paul E. Jones 22 Feb '01

22 Feb '01

Folks, As you know, requests for document numbers for the upcoming Rapporteur's meeting are due by 23 February 2001. Unfortunately, I will be traveling on that day, so I will not be able to reply to requests received on that day. Most likely, I will not get a chance to reply until the 25th-- I do apologize. However, please be assured that I will respond to your request at my earliest opportunity. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Q: H.245 and RTP Dynmaic Payload Types
by Douglas Clowes 22 Feb '01

22 Feb '01

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

2 1

Re: Protocol version re-negotiation
by Paul Rheaume 22 Feb '01

22 Feb '01

Folks, Where is the appropriate list to discuss this issue? We feel that version negotiation and the version upgrade process is not well specified and needs to be discussed and properly defined at the latest in version 2 of the specification. That means looking at this very soon. I think this issue belongs to the next version of the Implementor's Guide. Regards, Paul Nancy Devin wrote: > > How does a non-redundant MG upgrade to a new > Megaco version without affecting service? How > does a redundant MG upgrade to a new Megaco > version without affecting service? > > It is mentionned in RFC3015 that Protocol version > negotiation can be done at Restart, Failover, and > Handoff serviceChanges. It is not mentionned > explicitly how version protocol re-negotiation is > done after the MG has registered with the MGC. in > both situation > > This could be done in at least two different ways > as listed bellow. > > 1- Protocol version negotiation could be > initiated using the Failover serviceChange. A > Failover serviceChange with a protocol version > would indicate that the MG has been configured > with a new H.248 protocol version. Sent from the > MG to the MGC, it indicates that the MG has been > configured with a new H.248 protocol version. > This serviceChange shall not indicate Failure of > the working MG. This would require that for > non-redundant MGs, both the primary IP address and > the secondary IP address be the same. > > 2- Protocol version negotiation could be > intiated using a new serviceChange method: > VersionNegotiation (Method 7 of the serviceChange > command as defined in RFC3015) This serviceChange > would be sent from the MG to the MGC to initiate > protocol version initiation. It indicates that > the MG has been configured with a new H.248 > protocol version. Sent from the MGC to the MG, it > indicates that the MGC has been configured with a > new H.248 protocol version. > > Comments please. > Nancy

1 0

AVD-2033 and AVD-b2034, H.248 Annex F corrections
by Gunnar Hellstrom 22 Feb '01

22 Feb '01

I have uploaded the following documents to the avc-site/incoming for the coming Q.3/16 meeting: AVD-2033.zip H.248 Annex F corrections. AVD-2034.zip H.248 Annex F Implementor´s guide proposal. The contributions proposes correction of errors in assigned numeric parameter values. (Annex F is the Fax, Text, Call discrimination packages ) Regards Gunnar Hellström **************************************** Gunnar Hellström Ericsson Radio Systems AB tel´+46 708 204 288 gunnar.hellstrom(a)era.ericsson.se ***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

a query
by Alok Dubey (OCS-BLRAKS-AVS) 22 Feb '01

22 Feb '01

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

2 1

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 21 Feb '01

21 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

Transfer Mode encoding in Bearer Capability
by Aggarwal, Mitu 20 Feb '01

20 Feb '01

The encoding of the Bearer Capabilities as defined by H.225 version 2 specs in section 7.2.2.1, says that the Transfer Mode SHALL specify "circuit mode". Can anyone tell me why H.225 chooses to use "circuit mode" instead of "packet mode"? Q.931 in fact specifies that this field should be encoded as "packet mode". Regards, Mitu Aggarwal Intel Corp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

suscribe
by Aziz ABOUCHI 20 Feb '01

20 Feb '01

1 0

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

19 Feb '01

Dear Stephan, experts, thank you for your exact description of the current situation concerning the H.263 software. Unfortunately, other parts of your email are quite confusing I guess. I will try to clarify several points. First of all - fairness. We consider it unfair to use a professional, for speed and quality, optimized version of the software instead of an officially available H.263/L. I myself are involved in H.26L standardization, as you know. It's not a secret. I was involved in H.263 standardization as well. I can't see any unfairness in working for different groups of the ITU or knowing other people working for other parts of the organisation. Several times we stressed the point that the results have to be reproducible by everybody. An official version of the software should be used. The test scenario should be agreed on by both parties. If there is anything missing to exclude one-sided advantages please let us know. We are completely aware of possibly technical changes of H.26L. We are not going to optimize Annex I for any special video codec. Using it is a pragmatic solution to the problem of the lack of officially available software for H.263. >From a university point of view it might look different. For companies H.263 is reality and H.26L will be the next standard used in products. Caused by the AAP adopted by the ITU standards will arrive much earlier at the market now. Hope this helps everybody to understand our intentions. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Gesendet am: Freitag, 16. Februar 2001 03:12 > An: Baese Gero > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: AW: H.323 Annex I > > Dear Gero, > > At 05:32 PM 2/14/2001 +0100, Baese Gero wrote: > > [...] > > >If there is no official software available for H.263 containing > >all annexes needed for the tests, as Stephan Wenger pointed > out, we can > >only restrict ourselves to H.26L. Otherwise we are not comparing our > >methods but rather special implementations of a video coding > standard. > > I don't believe it be wise to resort on H.26L, for at least > three reasons: > > 1. H.26L is in a relatively early stage of standardization, > and especially > the network adaptation layers are bound to change > significantly. While > there is a controlled software available, this software is > going to change > often at least for another year. Not a good start if you > want to have > reproducible results. > 2. Due to its computational complexity and due to the timing of > standardization and development of H.26L, it will likely take > several years before the first H.26L products will be > available. Hence > there is little point to rush out an Annex I that is optimized > (explicitly or implicitly) for H.26L. And, once it is out, it will > probably not see deployment in the mobile field at first, again > due to its computational complexity. > 3. An argument of fairness: Thomas Stockhammer, one of the key > contributors of the error resilience / NAL work in H.26L, > is somewhat > attached to the Siemens/HHI/TU Muenchen group. Not exactly fair, > considering that, as far as I know, UCLA and Samsung are not > directly involved in the H.26L standardization process. H.263++, > in contrast, is a ratified standard and thus gives anyone a chance > to implement it the best way he/she can. > > I don't really know why I bother to write this EMail at all; you know > my position on Annex I in general... I guess, point #3 and a personal > inclination to fairness is my main reason. > > Stephan > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 4

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

19 Feb '01

Dear Mr. Villasenor, experts, we completely agree using H.263 would be worthwhile. Using H.263 and H.26L was requested by the group at the Geneva meeting. Unfortunately there is no appropriate H.263 software available at the ITU. For H.26L the software exists. We raised the question at the meeting already. Since then we tried to find a solution with the representative of your department. Unfortunately we've got the first answer but now. Now the deadline is approching and our proposal (to restrict ourselves to H.26L) was a pragmatic solution to get comparable results for the meeting. We also want to use H.263, on the other hand using proprietary software wouldn't provide the group with material to base a decision on. Additionally it would be an enormous advantage for one side. Hopefully our intention is better understandable now and you are supporting a quickly reached decision based on our proposals. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: John D. Villasenor [mailto:villa@icsl.ucla.edu] > Gesendet am: Sonntag, 18. Februar 2001 01:15 > An: Gero.X.Baese(a)MCHP.SIEMENS.DE; adamli(a)icsl.ucla.edu; > cITU-SG16(a)mailbag.cps.INTEL.COM > Cc: baronson(a)ieee.org; jeonghoon(a)samsung.com; jfahlen(a)icsl.ucla.edu; > paulej(a)packetizer.com; soyoung_kim(a)samsung.com; ttian(a)icsl.ucla.edu; > villa(a)icsl.ucla.edu; yllee(a)samsung.com > Betreff: RE: AW: H.323 Annex I > > > Dear experts, > For what it is worth, I also strongly support using H.263 in this > work. If we base the work on 26L, we not only have the problems > pointed out regarding working with a pre-standard algorithm, > but we would in addition be ignoring the very important and very > relevant problem of the specific performance of Annex I when combined > with H.263. This particular problem is of high importance to > implementers in the short and long term. We owe it to ourselves > and to the other potential users of Annex I ensure its suitability > with the underlying video algorithm with which it is most likely > to be used for the foreseeable future. > Thanks, > John Villasenor > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Affiliate agreement
by ye＠CYTANET.COM.CY 18 Feb '01

18 Feb '01

Dear Sir, May we introduce ourselves as an IP Telephony company. At the end of this month (March 2001) we will launch our IP Telephony network. We have installed 60 line gateways in Russia, Ukraine, Bulgaria, Albania, Greece, Cyprus, Lebanon, Yemen, Egypt, Ivory Coast and Pakistan. Our hardware system is "Vocaltec" and the billing system is "Mind". We are very interested to enter into an affiliate agreement with your company and use your network to terminate our traffic in the rest of the world i.e. in the countries that we do not have point of presence with a gateway. For this reason we would appreciate if you send us your best termintion rate sheet. At the same time we are interested to terminate your traffic in the countries we have installed our gateways and you do not have any point of presence. If you are interested for such an arrangement we would appreciate if you let us know how much you can offer to pay per minute to terminate your traffic through our gateways in the above countries. We look forward to your prompt reply. Regards John Emmanuel Marketing Manager ED Mercury Communications Ltd. 9, Tagmatarchou Pouliou St. Ayios Andreas, P.O.Box 7086, Nicosia, Cyprus Telephone : +3572 863 700 Fax : +3572 499 560 email : ye(a)cytanet.com.cy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: AW: H.323 Annex I
by John D. Villasenor 17 Feb '01

17 Feb '01

Dear experts, For what it is worth, I also strongly support using H.263 in this work. If we base the work on 26L, we not only have the problems pointed out regarding working with a pre-standard algorithm, but we would in addition be ignoring the very important and very relevant problem of the specific performance of Annex I when combined with H.263. This particular problem is of high importance to implementers in the short and long term. We owe it to ourselves and to the other potential users of Annex I ensure its suitability with the underlying video algorithm with which it is most likely to be used for the foreseeable future. Thanks, John Villasenor

1 0

Meeting Registration Deadline reminder
by Christian Groves 17 Feb '01

17 Feb '01

Dear Sg16 experts, Please be reminded that the deadline for registrations with the meeting host for the Launceston WP2/16 meeting is on the 19th of February. Please register your participation ASAP to assist the host with planning for the meeting according to the host's invitation at the ftp site: http://standard.pictel.com/ftp/avc-site/0103_Lau/Ericsson_invitation_a.zip Regards, Christian Groves Dear SG16 experts, The Launceston meeting of WP2/16 experts is rapidly approaching. Please be reminded that the SG16 management requires a sufficient number of participants AND contributions to justify holding a Rapporteur meeting. Please register your participation and submission of contribution as quickly as possible according to the host's invitation and the meeting notice available at the ftp site: ** Participation: Send your form in http://standard.pictel.com/ftp/avc-site/0103_Lau/Ericsson_invitation_a.zip to the meeting host not later than 19 February. ** Document submission: Ask P Jones <paulej(a)packetizer.com> for AVD-xxxx number according to the procedure in http://standard.pictel.com/ftp/avc-site/0103_Lau/Notice_AVD_Launceston.txt by 23 February at the latest. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0