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

H.323 Overhead
by Christopher Iles 12 Feb '00

12 Feb '00

Hi all Would someone know the % of overhead in H.323 & H.320 Thanks for any help you can provide Chris Christopher Iles Senior Technologist COMMUNICATIONS RESEARCH CENTER e-mail: christopher.iles(a)crc.ca 3701 Carling Ave Tel office: 613 998 2734 Ottawa, Ont. K2H 8S2 Ops Room : 613 998 2374 ATTN: BLDG 46

4 3

URGENT question on draft-ietf-avt-tones-07
by Stephen Casner 12 Feb '00

12 Feb '00

To the IETF AVT working group and ITU SG16: --> Interested parties need to respond by end of day PST Monday 2/14 <-- The following has come up during IESG discussion of the draft-ietf-avt-tones-06.txt document: > In section 3.11 there are two events (CRd and MRd) where the signals > are different for the initiator and the responder. > This implies that the entity doing the translation between audio and events > need to be aware of the higher layer roles of the communicating peers. > Is this a reasonable assumption? This appears to be a valid concern that we did not realize in the working group review of this document. One would want the gateway that is doing the translation from an event to a tone to not be required to know the higher layer roles. It would be possible to give two different codepoints to each of these events. I don't know if there has already been enough implementation of this protocol that this would cause a problem, and the purpose of this message is to find out. Given that the modem and fax tones were added fairly late in the development of the draft, I suspect is would not be a problem to add two codepoints in that section (32-47) without changing the other sections. The author (Henning Schulzrinne) agreed: > This is at least ambiguous, particularly for a "pass-through" gateway > that's pretty clueless as to call state. There are effectively four tone > sequences > > 1375/2002 followed by 1150 > 1529/2225 followed by 1150 > 1357/2002 followed by 1900 > 1529/2225 followed by 1900 > > My suggestion would be to split the Crd and Mrd into Crdi and Crdr for > the initiating and responding side. Same for the other pair. The draft has been revised to make this split, so the codepoints 41-49 are now different. The revised draft has been submitted but is available in the meantime as: http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.txt http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-tones-07.ps I believe that, subject to this change, the draft has been approved by the IESG. If there are no objections from the working group by the end of the day PST on Monday (2/14), then I will give our OK for the -07 draft be sent to the RFC editor. This is a very short response time, but our goal is to get the RFC number assigned before the end of the SG16 meeting on 2/18. To those at the SG16 meeting, please call this issue to the attention of interested parties that might not have seen this message. -- Steve Casner

2 1

Re: H.323 Overhead
by Ami Amir 12 Feb '00

12 Feb '00

Hi Steve and All Video does not gain from silence suppression. The equivalent to "silence" is no motion. H.261 was really designed for constant GOBS per second (Group of Blocks). The number of GOBs varies by the level of compression and quality (CIF vs QCIF). No motion = a GOB which is practically empty - which creates a packet that is only overhead => not very efficient. Since this the 'best case" situation as far as total bandwidth taken up by the video stream, I would not worry about it. When there is lots of motion - the GOBS are very big, and the frame size is really the maximum RTP frame allowed by the network. When this occurs, the overhad is negligible. To summarize - for H.323 (it is really for RTP - since all protocols i.e. SIP and MEGACO/MGCP/.... use RTP) the more data you send - the lower the overhead. H.323 signaling overhead is practically nill (again like SIP and MGCP). Signaling information is sent only when there are changes - e.g. call set up or tear down. As Steve correctly states - the only real issue is at the edge (say PPP connections via RAS - remote access modems). This is the place where the attention needs to be placed, i.e. header compression etc. H.320 (H.221 really) was designed for maximum efficiency in TDM circuits. H.221 sacrifices simplicity for bandwidth. The data is NOT organized in bytes and requires a lot of bit manipulation. Overhead is really neglible. As far as I remember - for 128kbps - it is less than 5%. Ami -----Original Message----- From: Stephen Casner [mailto:casner@CISCO.COM] Sent: Friday, February 11, 2000 6:34 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Overhead On Fri, 11 Feb 2000, Francois Menard List Account wrote: > In terms of the overhead related to > packets transmission, it is RTP encapsulation which is causing a lot of > overhead. Actually, the 12 bytes of RTP aren't the biggest part. There's also 8 for UDP, 20 for IP, and some more for a link-level header. But the IP/UDP/RTP part can be compressed down to a few bytes across links where that matters. This compares to the H.221 overhead for H.323 -- I don't know that number. But in the IP case, you also gain from silence suppression, which I believe is only done on specialized links in the circuit case. In my opinion, the focus on transmission overhead is misguided. If you believe predictions that voice bandwidth will be a small fraction of the converged IP network, then that overhead in the backbone should not be an issue. Header ompression can be used on narrow links at the edges. -- Steve

1 0

Re: Description of EndpointAlias in URQ??
by Jane Hua 11 Feb '00

11 Feb '00

So let me ask Frank's question this way: If a E.164 address is assigned and I want to unregister only few of my Call Signalling addresses, do I have to unregister my E.164(assigned one) also? Regards, Jane > >>>>> "Frank" == Frank Derks > <frank.derks(a)PHILIPS.COM> writes: > > Frank> The "explanatory" text of the EndpointAlias > element in the > Frank> URQ message, contains the following > sentence: "The E.164 > Frank> address, if assigned, is required. " This > sentence would seem > Frank> to indicate that if I am unregistering, I > always have to > Frank> unregister the assigned E.164 address??? > The sentence that > Frank> follows, contradicts this: "Only values > listed here are > Frank> unregistered; this allows, for example, an > H323_ID to be > Frank> unregistered while leaving the E.164 > address registered." > > Frank> What is the intention of this sentence? > Should I simply > Frank> ignore it? > > IMO, the sentence means "The E.164 address, if > assigned [dynamically > by the GK during registration procedure], is > required". > > Regards. > Fix. > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

2 1

Description of EndpointAlias in URQ??
by Frank Derks 11 Feb '00

11 Feb '00

The "explanatory" text of the EndpointAlias element in the URQ message, contains the following sentence: "The E.164 address, if assigned, is required. " This sentence would seem to indicate that if I am unregistering, I always have to unregister the assigned E.164 address??? The sentence that follows, contradicts this: "Only values listed here are unregistered; this allows, for example, an H323_ID to be unregistered while leaving the E.164 address registered." What is the intention of this sentence? Should I simply ignore it? Frank

3 2

Re: H.323 Overhead
by Ami Amir 11 Feb '00

11 Feb '00

Hi Chris What do you mean by overhead - is it the ratio between th enet payload and the header and packet total size? Ami -----Original Message----- From: Christopher Iles [mailto:christopher.iles@CRC.CA] Sent: Friday, February 11, 2000 3:57 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Overhead Hi all Would someone know the % of overhead in H.323 & H.320 Thanks for any help you can provide Chris Christopher Iles Senior Technologist COMMUNICATIONS RESEARCH CENTER e-mail: christopher.iles(a)crc.ca 3701 Carling Ave Tel office: 613 998 2734 Ottawa, Ont. K2H 8S2 Ops Room : 613 998 2374 ATTN: BLDG 46

2 1

terminalAlias or endpointAlias??
by Frank Derks 11 Feb '00

11 Feb '00

The RRQ and RCF messages may contain a field with the name "terminalAlias". The GRQ, URQ and IRR, contain an element with the name "endpointAlias". It would seem that these two differently named fields are actually referring to the same thing. Is there a distinction or is this just something that happened for no particular reason? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

Files in the PictureTel ftp site
by Sakae OKUBO 08 Feb '00

08 Feb '00

Dear Q12-14/16 experts, Please be advised that I have belatedly cleaned the /Incoming directory of the PictureTel ftp site. 1) All the mobility files have been moved to a new directory /avc-site/Mobility-adhoc. 2) All the documents for the current SG16 meeting in Geneva have been moved to /0002_Gen directory. 3) A list of documents in /0002_Gen directory is given by /0002_Gen/0002_Gen.html. 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 ***********************************************************

1 0

Incorrect Source on COM16-D392
by Chip Sharp 05 Feb '00

05 Feb '00

Contribution COM16-D392 titled " Call linkage in H.323" currently lists Cisco Systems, Inc. as one of the sources. Cisco Systems, Inc. is not one of the sources of this contribution. This implies neither that we oppose the contribution nor that we support it. This can be discussed during the course of the meeting. I apologize for any confusion this may have caused. See ya' soon. Thanks, Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Unregistration procedure problem
by Henri M�enp�� 03 Feb '00

03 Feb '00

Hello, I'm having diffuculties understanding the correct behaviour of Unregistration procedure. H.225v3 states in URQ 7.10.1: "callSignalAddress - This is one or more of the transport call signalling addresses for this endpoint which are to be unregistered." Also, a registered endpoint must have always at least one callSignallingAddress. Right? Say, there's one callSignallingAddress and two endpointAliases registered for an endpoint. If this endpoint now wants to unregister one of the aliases, it has basically two options. 1) One would be to send URQ with only this one endpointAlias included (the one that is to be deleted). Because callSignallingAddress is mandatory in URQ message, the only callSignalAddress would become deleted also according to the standard quote above. This is an error, I think. 2) The other option would be to send a new RRQ that specifies only the endpointAlias that shall be kept "active". In this scenario the problem does not occur. Any comments? Henri Mäenpää, Nokia.

1 0