- sg16-avd - lists.packetizer.com

H.323: Annex-H editor
by Edgar Martinez [1] 17 Feb '00

17 Feb '00

Dear SG16 Mobility: I was informed that: >Dale Skran, the Q13 > Rapporteur, was not happy in that he only learnt that you were not coming > after the meeting started - he did not get any message from you. I had sent email to Dale and AT&T one week before the meeting started that I could not attend (copy below). I been re-assigned to help out in other IP area's in Motorola. The work in SG16 is very important to Motorola and will continue to support SG16 and the Mobility-Ahoc Group. As for the editorship for Annex-H. I request that a permanent Editor be assign, since I will be more heavily involved in more ALL IP mobile standards. Standard meeting conflicts are already taking a toll on my time. I will still be kept informed on the SG16 mobility work, and will provide contributions and comments at the appropriate times. In our profession reassignment happens all the time, and I am happy to say that IP support is growing so fast that we have become value resources. Best Regards to all, Ed > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@cig.mot.com] > Sent: Tuesday, February 01, 2000 1:13 PM > To: Roy, Radhika R, ALARC; dskran(a)ascend.com > Subject: Geneva-2000 ITU > Importance: High > > Dear Dale and Radhika, > > I having work related problems here, and at the moment > I am not planning to go Geneva. Please put a > Temporary Editor in my place. > > Best Regrads, > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Roni Even 17 Feb '00

17 Feb '00

Gary, About videoNotDecodedMBs Appendix I/H.263 explains the macroblocks numbering from 1 to N, it looks consistent with H.245 to me. Appendix I/H.263 Assume N macroblocks within each frame enumerated mb = 1...N from top-left to bottom-right. Let {nerr, mbfirst, mblast} be the feedback message to the encoder, where mbfirst * mb * mblast indicates a set of erroneous macroblocks in frame nerr. H.245 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/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. I see the problem with videoFastUpdateMB Roni Even ********************************************** Roni Even VP Product Marketing Accord Networks Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Gary Sullivan [SMTP:garysull@MICROSOFT.COM] > Sent: Sun, February 13, 2000 9:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.245 for videoFastUpdateMB, videoFastUpdateGOB, > videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) > > > > > > 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

Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by ari.hourunranta＠NOKIA.COM 16 Feb '00

16 Feb '00

Hi I am not giving any answers, but rather pointing out more problems related to the topic. In videoFastUpdateMBs, the statement saying that firstGOB is only relative to H.263 and firstMB is only relative to H.261 sounds weird. You could interpret it so that if you are using H.263 Annex K (slices), you should still request updates for GOBs, although MB-level start index would be much more natural. In case of MPEG-4 visual, use of videoFastUpdateMBs seems to be forbidden, although there is no technical reason why it should be (maybe political?). I am sure most of the implementors use common sense when interpreting the specifications, but still it wouldn't harm if the specification would be understandable. Regards, Ari ------------------------------------------------------------ Ari Hourunranta Nokia Mobile Phones ari.hourunranta(a)nokia.com ------------------------------------------------------------

1 0

question on video transcoder or gateway
by wmshen 15 Feb '00

15 Feb '00

Hello, all experts, I am a Ph.D student working on video communication. I am wondering about how the video transcoder/gateway works between H.261 and H.263, and between IP network and PSTN or ISDN, in paticular i wonder whether there is a method by which bitstreams can be translated directly between H.261 and H.263 format. Who knows the technique details on above topics or where may i get some useful reference infomation? Any help will be approciated. Weiming Shen

1 0

[Fwd: Re:ALL-IP workshop held on 7-9 Feb 2000 in Nice (News release & Docs)]
by Edgar Martinez [1] 15 Feb '00

15 Feb '00

FYI -------- Original Message -------- From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Subject: Re:ALL-IP workshop held on 7-9 Feb 2000 in Nice (News release & Docs) To: TIPHON : Entirely <TIPHON(a)LIST.ETSI.FR> Dear Scott, The work shop I believe was done to benefit both MWIF and 3GPP. What do they have that we do not? 3GPP and MWIF are addressing the Radio Access interface on IP. Motorola has try to include the Radio Access into TIPHON WG7 but have not progress too far. If TIPHON really wants to get into the full end to end fixed and wireless/mobility network All IP solution. We need to address IP Radio Access. We need to work with Tiphon's WG2 architecture team and add a Radio Access Plane. So we can recommend requirements around the Radio (wireless) access plane. In any event without the Radio access on IP we have "no real Wireless mobility with handover" same problem in SG16. Right now both SG16 and TIPHON is working only on Roaming! Motorola will again try to bring up the issue of the direct radio access IP interface to the IP network and adding a Radio Access Plane to the TIPHON architecture. In the next TIPHON meeting and I hope we can get more support. I hope we also Liaison with MWIF and other wireless all IP groups looking for an "real" all IP end to end solution. And not just use the IP network (TIPHON) as a simple VoIP/media Transport or simple Home Location database depository for a 3G Hybrid Mobile Network as it has been proposed in other groups. Ed Scott Cadzow wrote: > This is a summary and pointer to the 3GPP all IP network workshop. It should > be stressed that TIPHON on offering to present our work were brushed aside > and not invited to this workshop. > > Regards, > > Scott > > -----Original Message----- > From: Adrian Zoicas [mailto:Adrian.Zoicas@ETSI.FR] > Sent: 15 February 2000 17:09 > To: UMTS(a)LIST.ETSI.FR > Subject: UMTS mail#15: ALL-IP workshop held on 7-9 Feb 2000 in Nice > (News release & Docs) > > Will the next generation be ALL-IP? > [2000-02-11] A workshop held on 7-9 February 2000 in Nice - France hosted by > Microsoft gathered together over 350 participants to investigate what is one > of the biggest things to hit the 3rd Generation Partnership Project (3GPP) > since its creation! The Internet Protocol (IP) has the ability to achieve > seamlessness across networks, it is believed to be the solution for reducing > the cost of creating and expanding mobile networks and to allow IP-based > services to be rapidly developed for use upon them. > There is already a substantial amount of IP equipment installed for internet > infrastructure and the new challenge is how to re-use this for mobile > networks? > The aim of this workshop was to firstly come up with some clear ideas of > what an All-IP network is - a common understanding is essential to commence > work. It is also necessary to have a common vision with regard to future > phases of All-IP. > The next step will be to integrate the results of these discussions into the > work of each of the 3GPP TSGs. The first phase of the work, establishing > detailed requirements, will be part of 3GPP release 2000. This is due for > completion in December 2000. Co-operation with other bodies, such as the > Internet Engineering Task Force (IETF), will certainly be required. > There are still issues that need to be resolved regarding where to use IP > transport, the requirements for naming and addressing; Mobility Management, > which IP version to use (IPv4 or IPv6) and how to migrate to the chosen IP > version, ..... > http://www.etsi.org/tbnews/Previous/all-IP2000feb.htm > > PS: Documents from the workshop can be found at: > ftp://ftp.3gpp.org/WORKSHOP/0002IP/Docs/ > e.g.: > > AIP-000002 > List of presentations > > AIP-000003 > Defining standards that merge Mobile systems with Internet > Ericsson > > AIP-000004 > Architectural principles > Ericsson > > AIP-000006 > Liaison on All-IP from GSM North America > GSM North America > > AIP-000007 > Next Generation Wireless: Business Drivers for an All-IP network > Lucent Technologies > > AIP-000008 > All IP: Issues Requiring Direction and Decision > Lucent Technologies > > AIP-000009 > Requirements for IP Based UMTS. A Consensus View from the Industry > UMTS Forum > > AIP-000011 > Business Drivers for the IP Based 3G Vision > BT > > AIP-000012 > Evolving Towards the IP Vision > BT > > AIP-000013 > Naming/Numbering and Identification of UMTS Users > BT > > AIP-000014 > Web-Based Network Management for IP Networks > Motorola > > AIP-000015 > Voice and Data legacy Systems - IP interworking > MATRA Nortel Communications > > AIP-000016 > All IP Networks Vision and Migration > Motorola > > AIP-000017 > IP Wireless Network > Cisco Wireless Architecture > > AIP-000020 > All-IP standardisation > GSMA ISG > > AIP-000021 > Report of SA WG2/CN Release 2000 ad-hoc/T WG2 Joint meeting on Release 2000 > > MCC > > AIP-000022 > All-IP Networks Architectures Convergence Mid term vision > Alcatel > > AIP-000023 > 3G TR 22.976 V0.5.0 (ad-hoc group draft) > R Wohlert > > AIP-000024 > Key Results from CN R'00 Ad-Hoc > TSG CN Vice Chairman > > AIP-000025 > Requirements for All-IP. A view of a "Legacy Network" Operator > Mannesmann Mobilfunk > > AIP-000026 > Mobile Wireless Internet Forum (MWIF) Architectural Principles > Vodafone AirTouch > > AIP-000027 > IP based unified networking > Nortel Networks > > AIP-000028 > Nokia Vision of the Mobile Information Society > Nokia > > AIP-000029 > Nokia All-IP System Design Principles > Nokia > > AIP-000030 > Defining standards that merge Mobile systems with Internet > Ericsson > > Best regards > Adrian ZOICAS > ETSI Mobile Competence Centre > mailto:adrian.zoicas@etsi.fr Tel:+33492944221 Fax:+33492385221 > http://www.etsi.org/umts > http://www.3gpp.org > > ------------------------------------------------------------------- > Mail archive for TIPHON can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

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

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

Draft H.450.9 Call Completion Supplementary Service
by Karl.Klaghofer＠ICN.SIEMENS.DE 02 Feb '00

02 Feb '00

I have uploaded the latest draft of the H.450.9 Call Completion Supplementary Service to the standard.pictel.com ftp site. ftp://standard.pictel.com/avc-site/Incoming/h450.9.zip Regards, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

1 0

[Robustness] Some Open Issues for Geneva meeting
by Maureen Stillman 31 Jan '00

31 Jan '00

Based on the robustness group teleconferences, RadVision has submitted a delayed contribution named: RV-Robustness.zip available at: http://standard.pictel.com/ftp/avc-site/Incoming/RV-Robustness.zip In addition to this submission, here is an incomplete list of open issues for robustness. Most of these have been discussed in teleconferences or on the mailing list. Please send any open issues to the mailing list and we can discuss them further in Geneva. Thank you. Open Issues 1) How does robustness interact with billing? There are concerns about keeping a call alive that can't be billed for properly. 2) Does an endpoint need to reregister with the gatekeeper after it crashes and comes back up? When does it perform this process? Suppose endpoint A and B are registered with the same gatekeeper. After B crashes and it comes back up should it initially try to recover a call that is in progress? Then, if no calls are in progress, should go ahead with gatekeeper discovery or perform gatekeeper discovery immediately? This scenario raises security issues.... 3) How does security interact with robustness? For example, does an endpoint need to re-authenticate when it (or a gatekeeper) crashes and comes back up? (answer should be "yes".) How? There are concerns that the robustness mechanism will introduce security holes. 4) What identifier (CALL ID???) will be used when H.225 and/or H.245 connections are reopened? RadVision's submission suggests we use the CALL ID. 5) How will the H.225 and H.245 connections be reopened? (This might belong in the implementers guide) 6) There has been considerable debate on whether or not we allow the H.225 connection to be closed during a call. Should we change the standard to say that it can't be closed? 7) The standard states that if the H.245 connection is closed then the call is terminated. How does this fit in with robustness procedures? Should we change this requirement in the standard? 8) (from the mailing list) If an endpoint fails to find a gatekeeper during gatekeeper discovery, it is permitted to assume that there is no gatekeeper around, and that it may therefore make calls without using a gatekeeper. It might be considered "polite", however, for an endpoint carrying on this way to periodically check up to see if there ARE any gatekeepers around. At least one well-known H.323 stack acts in this way if asked to handle RAS for its application. The question is what should it do if it should find a gatekeeper at this later stage? 9) Is support for robustness mechanisms in H.323v4 mandatory or optional? -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0

WP2 agenda and schedule
by Sakae OKUBO 31 Jan '00

31 Jan '00

Dear Q12-14/16 experts, I have placed the draft agenda and meeting schedule of WP2/16, which were received from Mr. Tosco, Chairman of WP2/16. ftp://standard.pictel.com/avc-site/Incoming/Draft_agenda_WP2_Feb_00.doc or http://standard.pictel.com/ftp/avc-site/Incoming/Draft_agenda_WP2_Feb_00.doc ftp://standard.pictel.com/avc-site/Incoming/Work_Plan_WP2_Feb_00.xls or http://standard.pictel.com/ftp/avc-site/Incoming/Work_Plan_WP2_Feb_00.xls 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

Re: Delayed contributions
by Mike Nilsson 31 Jan '00

31 Jan '00

It has just been brought to my attention that this ftp site is not accessible outside of BT, and that files in this area are automatically copied to an external site overnight. So, I hope that these files will appear in the directory http://www.labs.bt.com/people/nilssome/APC tomorrow. Apologies for wasting your time and causing confusion. Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Mike Nilsson [SMTP:mike.nilsson@BT.COM] > Sent: Monday, January 31, 2000 10:00 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Delayed contributions > > I have been unable to upload our delayed contributions to the PictureTel > site. > > So instead I have put them on a BT server as detailed below. > > ISUP transport in H.225 using a Generic, Extensible Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/extens%7E1.doc > > A Tutorial on the Extensible Package Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E1.doc > > Applying the Extensible Package Framework to Annexe G : > ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E2.doc > > Object Profile for ISUP Transport in H.225 using the Generic Extensible > Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/revise%7E1.doc > > Security package for the Extensible Package Framework : > ftp://sss.info.bt.co.uk/people/nilssome/APC/securi%7E1.doc > > Best regards > > Mike > > > ********************************************************************** > * Mike Nilsson Tel: +44 1473 645413 * > * Applications Technology Group Fax: +44 1473 645011 * > * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * > * BT Advanced Communications Technology Centre [B54 Room 94] * > * Adastral Park * > * Martlesham Heath * > * Ipswich IP5 3RE * > * UK * > **********************************************************************

1 0

Delayed contributions
by Mike Nilsson 31 Jan '00

31 Jan '00

I have been unable to upload our delayed contributions to the PictureTel site. So instead I have put them on a BT server as detailed below. ISUP transport in H.225 using a Generic, Extensible Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/extens%7E1.doc A Tutorial on the Extensible Package Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E1.doc Applying the Extensible Package Framework to Annexe G : ftp://sss.info.bt.co.uk/people/nilssome/APC/packag%7E2.doc Object Profile for ISUP Transport in H.225 using the Generic Extensible Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/revise%7E1.doc Security package for the Extensible Package Framework : ftp://sss.info.bt.co.uk/people/nilssome/APC/securi%7E1.doc Best regards Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * **********************************************************************

1 0

FTP server unavailable?
by Euchner Martin 31 Jan '00

31 Jan '00

Dear Webmaster and administrator of the ftp://standard.pictel.com/avc-site/ <ftp://standard.pictel.com/avc-site/> a couple to people are having access problems to reach the FTP server of Q12-14 of Study Group 16 since several days now. Accessing the FTP server results in the following error message (see below). Would you please check you web/ftp server for any potential problems? Thank you! Martin Euchner. Error The URL could not be retrieved. The reasons possible are : The proxy can not login into ftp server. Please check you username and password and try again. When the proxy send the command: USER Server Reply: 530-The server standard.pictel.com is temporarily unavailable due to 530-the number of users currently connected. The limit is 50 anonymous 530-users at one time. Please try logging in again; if you believe 530-that there is an issue beyond number of users, please e-mail 530-webberr(a)pictel.com to report the problem. 530- 530 User anonymous access denied. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/SG16_.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0