- sg16-avd - lists.packetizer.com

Re: Description of URQ??
by Henri M�enp�� 14 Feb '00

14 Feb '00

Hello, I asked this a while ago, but with no success. So, let's try again... This is about callSignalAddress in URQ. 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." So, unlike I have understood, this sentence would seem to say that I can not just unregister a single alias, but I must have "a spare" callSignalAddress to unregister as well... Does anybody else think this is not the way it should be? /Henri Mäenpää > -----Original Message----- > From: EXT Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: 11. February 2000 19:33 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Description of EndpointAlias in URQ?? > > > Frank, > > > 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". > > I wonder what this is doing here at all... > > Action that I consider sensible at a gatekeeper: > If any aliases are mentioned in URQ, just unregister those > aliases; if no > aliases are mentioned, unregister the user altogether (ie all > aliases). > > Action I consider sensible at an endpoint: > Mention all aliases that are currently registered! > > This may or may not tally with the way people read the spec!!! > > Regards > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 >

2 1

Re: Description of EndpointAlias in URQ??
by Frank Derks 14 Feb '00

14 Feb '00

Hi "Fix", I don't think that I understand your reply. Do I always have to unregister my E.164 (if assigned) address and if so why? 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 | ----------------------------------------------------- fxk@TIDWEB.GRENOBLE.HP.COM@SMTP@MAILBAG.INTEL.COM on 11/02/2000 16:41:07 Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Description of EndpointAlias in URQ?? Classification: Restricted >>>>> "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. -- Francois-Xavier KOWALSKI __________ Telecom Engineer Hewlett-Packard Company //_ o \\/ Telecom Infrastructure Division Tel:+33 (0) 4 76 14 63 27 // // /\\ Fax:+33 (0) 4 76 14 16 86 mailto:fxk@tidweb.grenoble.hp.com http://www.hp.com/go/opencall/

1 0

Re: H.323 Overhead
by Gary Sullivan 13 Feb '00

13 Feb '00

I don't entirely agree with the video comments below. Video codecs operating at low bit rates typically vary their frame rate (and thus their GOB rate) depending on the degree of visual activity in the scene. The overhead from H.323 packetization is far from negligible. Packetization schemes for video often allow the encoder to decide how much data to place in each packet. For example, RFC 2429 for H.263 allows up to a full picture in one packet. (It also allows the picture to be chopped into multiple packets if desired.) The larger the packet size, the lower the overhead (and the higher the delay). The overhead is *not* negligible -- I believe each H.323 packet adds a minimum of 40 bytes of overhead. (Stephan Wenger would be the authority on the packet overhead.) Some packetization schemes (see RFC 2190) advocate using a packet for every GOB. That's a bad idea. If you're running CIF resolution H.263 (18 GOBs per picture) at 15 frames per second, and if I'm right about the 40 bytes overhead per GOB, then that seems to work out to 86.4 kbits per second just for the overhead if you send each GOB in its own packet. That overhead rate is enough to send a second CIF resolution H.263 video stream! -Gary Sullivan +> -----Original Message----- +> From: Ami Amir [mailto:Amir@TLV.RADVISION.COM] +> Sent: Friday, February 11, 2000 11:46 PM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: H.323 Overhead +> +> +> 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

H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 13 Feb '00

13 Feb '00

This time copying the APC people as well, since they should be the H.245 gurus: +> -----Original Message----- +> From: Gary Sullivan [mailto:garysull@microsoft.com] +> Sent: Saturday, February 12, 2000 7:29 PM +> To: Thomas Wiegand (E-mail) +> Cc: ITU-T Q. 15/SG16 Advanced Video Coding Experts Group (E-mail) +> Subject: Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800 +> +> +> ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> Email from Gary Sullivan <garysull(a)microsoft.com>: +> +> +> To the U. Erlangen folks and other video experts, +> +> I have the strong impression that we have been here before discussing +> this same issue. I thought we clarified these issues in H.245. +> However, I'm looking at H.245 and I'm seeing what looks like some old +> (pre-1998) text. Since the records on this would be at +> least a couple +> of years old, I don't seem to be able to track them all down. +> +> I have questions about two paragraphs in H.245. Here's the +> first one: +> +> videoFastUpdateGOB SEQUENCE +> { +> firstGOB INTEGER (0..17), +> numberOfGOBs INTEGER (1..18) +> }, +> +> videoFastUpdateMB SEQUENCE +> { +> firstGOB INTEGER (0..255) OPTIONAL, +> firstMB INTEGER (1..8192) OPTIONAL, +> numberOfMBs INTEGER (1..8192), +> ... +> }, +> +> "videoFastUpdateMB commands the far-end video encoder to perform a +> fast update of one or more MBs. firstGOB indicates the number of +> the first GOB to be updated and is only relative to H.263, firstMB +> indicates the number of the first MB to be updated and is only +> relative to H.261 and numberOfMBs indicates the number of MBs to +> be updated. It shall only be used with video compression +> algorithms that define MBs, for example, H.261 and H.263. +> Terminals may respond to this command with a GOB update which +> includes the MBs requested." (If I now recall correctly, it was not U. Erlangen that put the above ambiguous statements into H.245 -- I believe they pre-dated the error tracking work.) Let me try a little more on the above: A GOB in H.261 is not a raster-scan-order set of macroblocks in a picture (instead it is a raster-scan-order set of macroblocks in a rectangle within the picture). But a GOB in H.263 is a raster-scan-order set of macroblocks in a picture. Reviewing GOB layout in H.261, each GOB contains 33 MBs. In H.261 CIF, GOBs are laid out in the picture like this: 1 2 3 4 5 6 7 8 9 10 11 12 In H.261 QCIF the layout is 1 3 5 and each GOB has a vertical size of 3 macroblocks and a horizontal size of 11 macroblocks. In H.261, MBs are numbered from 1 to 33 in raster scan order within each GOB. In H.263, GOBs are numbered like this in all picture sizes: 0 1 2 . . . The height of a GOB in H.263 depends on the height of the picture, with QCIF and CIF containing a single row of macroblocks per GOB and taller pictures containing 2 or 4 rows of macroblocks per GOB. So my guess is that when it is saying firstGOB is "only relative to H.263", it is saying that we should assume the GOB layout is in the manner of H.263. So that a GOB is synonymous with one or more rows of macroblocks. Then when it says firstMB is "only relative to H.261" I'm guessing it is saying that the MBs should be numbered starting from MB number 1 being the first MB in the GOB and then proceeding in raster scan order within the GOB. Does the above interpretation seem correct? If firstMB + numberOfMBs > 11, it's not clear what to assume. In H.261 this would address a GOB in the next row of MBs in the picture, but in H.263 there are other MBs in the same GOB and jumping to the next row of MBs in the picture would break my assumption that bitstream order would be the most reasonable. So my guess is that the order assumed in the scanning of MBs should depend on the bitstream order normal for the particular video codec in use. +> +> What the heck does "only relative to H.263" mean? +> What does "only relative to H.261" mean? +> What values are you supposed to send with this command? +> +> Here's the next one: +> +> videoNotDecodedMBs SEQUENCE +> { +> firstMB INTEGER (1..8192), +> numberOfMBs INTEGER (1..8192), +> temporalReference INTEGER (0..255), +> ... +> }, +> +> "videoNotDecodedMBs indicates to the far-end video encoder that a +> set of MBs has been received erroneously and that any MB in the +> specified set has been treated as not coded. The encoder may use +> this information to compensate transmission errors, as illustrated +> in Appendix I of H.263. firstMB indicates the number of the first +> MB treated as not coded, and numberOfMBs indicates the number of +> MBs treated as not coded. The MB numbering is done according to +> H.263. The temporal reference of the picture containing not +> decoded MBs is indicated in temporalReference. This indication +> shall only be used with the H.263 video compression algorithm." +> +> What does "numbering according to H.263 mean"? The only numbering +> defined in H.263 starts with macroblock number 0, not 1. Here my guess would be that MBs are numbered in raster scan order from 1 to the number of MBs in a picture. +> +> I really thought we fixed both of these problems two years ago. +> +> Best Wishes, +> +> Gary Sullivan +> +> +> ------------------------------------------------------------- +> ------------------- +> *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> Email List Message *** +> To send messages, address them to +> "itu-adv-video(a)standard.pictel.com". +> To subscribe or unsubscribe, send email to +> "majordomo(a)standard.pictel.com". +> Note: Only people whose exact email address is subscribed to +> the list can post. +> Subscriptions: "subscribe itu-adv-video +> YOUR-EMAIL-ADDRESS" in message body. +> Unsubscriptions: "unsubscribe itu-adv-video +> YOUR-EMAIL-ADDRESS" in message body. +> ------------------------------------------------------------- +> ------------------- +>

1 0

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