December 1997 - sg16-avd - lists.packetizer.com

Re: Typo in Gatekeeper discovery annex to H.225.0, etc.
by Tom Taylor 31 Dec '97

31 Dec '97

The discovery draft is at last call, on the way to be published as an experimental protocol RFC. >-----Original Message----- >From: Toby Nixon [SMTP:tnixon@MICROSOFT.COM] >Sent: Tuesday, December 30, 1997 8:38 PM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Typo in Gatekeeper discovery annex to H.225.0, etc. > >[Taylor, Tom (P.T.)] [snip] >Also, I read with interest >ftp://ietf.org/internet-drafts/draft-ietf-svrloc-discovery-05.txt, which >suggests using "Service URLs" in TXT records as a fallback when SRV lookup >fails. This differs from (although it is very close to) the format of RAS >information in TXT records currently contained in H.225.0v2. Of course, this >is just a draft, and I have no idea how well it was received in IETF, but if >it gets legs, we may want to also add support for RAS URLs in TXT records >via the H.323v2 Implementor's Guide. Regardless, it would be helpful to >include a pointer to this draft -- or even an H.323-specific modified >version of it -- in the Implementor's Guide to help people get gatekeeper >discovery via DNS correctly implemented. >

1 0

Suggesting Correction In H.235
by Lior Moscovici 31 Dec '97

31 Dec '97

There is a seeming inconsistency between the ASN.1 definition and section 10.3 in H.235: CryptoToken::= CHOICE { cryptoEncryptedToken SEQUENCE ? General purpose/application specific token { tokenOID OBJECT IDENTIFIER, token ENCRYPTED { EncodedGeneralToken } }, cryptoSignedToken SEQUENCE -- General purpose/application specific token { tokenOID OBJECT IDENTIFIER, token SIGNED { EncodedGeneralToken } }, cryptoHashedToken SEQUENCE -- General purpose/application specific token { tokenOID OBJECT IDENTIFIER, hashedVals ClearToken, token HASHED { EncodedGeneralToken } }, cryptoPwdEncr ENCRYPTED { EncodedPwdCertToken }, ... } According to section 10.3, additional choices for hashing and signature password based are needed: CryptoToken::= CHOICE { <OMITTED> cryptoPwdEncr ENCRYPTED { EncodedPwdCertToken }, <-- ************ ADD THE FOLLOWING:****************> hashedPwdEncr SEQUENCE { hashedTimeStamp TimeStamp, token HASHED { EncodedPwdCertToken } }, signedCertEncr SIGNED { EncodedPwdCertToken }, ... } Alternatively, one could use the general purpose cryptoSignedToken and cryptoHashedToken, but this is using non-standard (including an allocation of tokenOIDs) means to implement standard features... Lior.

1 0

Typo in Gatekeeper discovery annex to H.225.0, etc.
by Toby Nixon 31 Dec '97

31 Dec '97

I noticed that the annex to H.225.0v2 on gatekeeper discover using DNS refers several times to DNS "SVR" records. But when I look at RFC 2052 where these are defined (see <http://ds.internic.net/rfc/rfc2052.txt>), they are called "SRV" records. Am I looking at the right thing? If so, this is a typo that should be corrected before publication. Should H.225.0v2 include RFC 2052 as a reference? Has anyone yet applied to IANA to register "ras" as a service name? Also, I read with interest ftp://ietf.org/internet-drafts/draft-ietf-svrloc-discovery-05.txt, which suggests using "Service URLs" in TXT records as a fallback when SRV lookup fails. This differs from (although it is very close to) the format of RAS information in TXT records currently contained in H.225.0v2. Of course, this is just a draft, and I have no idea how well it was received in IETF, but if it gets legs, we may want to also add support for RAS URLs in TXT records via the H.323v2 Implementor's Guide. Regardless, it would be helpful to include a pointer to this draft -- or even an H.323-specific modified version of it -- in the Implementor's Guide to help people get gatekeeper discovery via DNS correctly implemented. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Fast Start issues
by Jim Toga 30 Dec '97

30 Dec '97

Tom, The answer to you question is ablsolutely yes. jimt. At 12:34 PM 12/18/97 -0500, you wrote: >I have what may be a simple-minded question relating to the availability >of media before CONNECT. In a situation where the called party is on >the GSTN, the terminating switch may return announcements or tones under >some circumstances. In an all-GSTN situation the caller would hear >these without getting billed. As a typical example, an announcement >might inform the subscriber that "The number you have reached is not in >service". Can we achieve this result with Fast Start, without >triggering billing? > >>-----Original Message----- >>From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >>Sent: Thursday, December 18, 1997 8:45 AM >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Re: Fast Start issues >> >>Scott, >> >>Thanks for your lengthy reply... >> >>What I was hoping to indicate was that for certain call scenarios you >>want media established before CONNECT, but for other scenarios this is >>not possible. >> >>A situation where you have to send CONNECT before the media is >>negotiated is when multiple phones are rang and the first one is >>answered. There are probably others. >> >>The point is that some flexibility is required on this point. >> >>I agree with your comments about mandating that fast start should allow >>for H.245 to be started at any time. I didn't contest the wording as it >>seemed to me that whatever wording was in the standard, if it suited a >>vendor they could quite easily ignore any request to do fast start. >>This would total destroy any attempt to deliver some services and is >>hence a problem for us. >> >>I'm also interested that you state that you are looking for light-weight >>systems that do not use H.245. Firstly this is in conflict with the >>wording at the moment. Secondly, it is only an illusion of a simpler >>implementation, as much of H.245 is being copied into H.225 (work out >>how much of H.245 is included into H.225 just by referencing >>Capability). >> >>As to how CONNECT works in the switched network, it seems that the >>called endpoint sends CONNECT before the bearer path is in place. The >>final switch will connect the bearer when it receives CONNECT. The >>CONNECT is then forwarded. The point is that the CONNECT is sent before >>the bearer is connected through, but the bearer is connect through by >>the time CONNECT is received. This is difficult to emulate in our >>environment. You can't just delay the CONNECT in the gatekeeper until >>the media is established because the user is concerned with the time >>from 'picking up the handset' to when they can speak and are not >>concerned with how this relates to the timing of the CONNECT message. >>Some one said the switched network delay in this instance is less than >>100ms. >> >>Regards, >> >>Pete >>================================= >>Pete Cordell >>BT Labs >>E-Mail: pete.cordell(a)bt-sys.bt.co.uk >>Tel: +44 1473 646436 >>Fax: +44 1473 645499 >>================================= >> >> >>>---------- >>>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>>Sent: 18 December 1997 01:52 >>>To: ITU-SG16(a)MAILBAG.INTEL.COM >>>Subject: Fast Start issues >>> >>>Friends, and especially Pete, >>> >>>It really does seem to me that it is possible to get everyone happy. I >>>would like to try and convince you (Pete) that: >>> a. you can get EXACTLY what you need, in the fastest, most correct >>>way >>>possible, right now, and >>> b. Intel's FastStart is really an important and useful thing as is >>>for >>>H.323. >>> >>>It is possible that a single sentence needs to be added to the >>>FastStart >>>text (see below in the paragraph starting "The thing that you >>>require..."). >>>But mainly I believe that there is a small misunderstanding going on, >>>which >>>is main the source of the problem. >>> >>>Pete, to get this extra "intelligence" you want, I believe that in most >>>cases you must use gatekeeper routed signalling. The called gatekeeper, >>>acting as a proxy for the called user, must send the H.245 port in the >>>CallProceeding message, H.245 negotiation must be used, and the CONNECT >>>message must come at the end, after all location/media negotiations are >>>over and media is available. >>> >>>I say "in most cases" because there are some cases where you will >>>probably >>>choose to do some intelligence in the LRQ phase, before the CallSetup >>>is >>>sent. In these cases it might be possible to know that the CallSetup >>>message is really being sent to the correct Terminal, and so you can >>>then >>>use FastStart to that Terminal. There are also other cases where you >>>may >>>choose to do FastStart with to the user's gatekeeper, have the >>>gatekeeper >>>play out a prompt saying something like "we are looking for your user >>>now", >>>have the gatekeeper do H.245 negotiation with the caller on behalf of >>>the >>>callee, and in the end establish a new media channel to the final >>>negotiated endpoint, breaking the original media channel negotiated >>>with >>>the gatekeeper in the FastStart. All this can be done now by using a >>>combination of FastStart and "classic" H.323 signalling. >>> >>>The "misunderstanding" I was alluding to earlier is this: you are >>>correct >>>that most endpoints until now unfortunately did CONNECT before media >>>negotiation. This is a very unfortunate breaking of Q.931 semantics >>>which >>>could have been avoided, and we should try hard to return to the normal >>>situation where CONNECT is sent only at the end of the entire call >>>establishment procedure. My problem is with the 2nd requirement you >>>gave in >>>an earlier posting: >>> >>>>we want to delay establishing media until after >>>>CONNECT so that the gatekeeper can do some intelligent stuff. >>> >>>I definitely DON'T want to delay establishing media until after >>>CONNECT. >>>And I claim that this is NOT needed for the gatekeeper to do some >>>intelligent stuff. >>> >>>The thing that you require, that is not quite there in the current >>>FastStart proposal, is that "even if a connection is made using >>>FastStart, >>>it shall be possible for either endpoint to start H.245 negotiation at >>>any >>>point in the conversation". I would be willing to go with this in the >>>spirit of compromise. (although personally I feel that such "shalls" >>>are >>>about as strong as "An H.uman endpoint shall not eat pork." Lot's of >>>people >>>who claim "Bible compliance" do not follow this shall, and somehow the >>>world continues to interoperate...) >>> >>>We at VocalTec, as part of our CMA work, support many of the scenarios >>>you >>>talk about, and we do it quite quickly (we think as quickly as >>>logically >>>possible in fact). Some of them require H.245, some require gatekeeper >>>routed signalling, some can be done with FastStart alone. >>> >>>I want to go on record saying that we DEFINITELY want to encourage >>>finishing the H.245 negotiation before CONNECT if it happens. This >>>function >>>is in H.323 now, and it is *the thing* that allows us to do the >>>scenarios >>>that Pete seems to want. We believe that this is how complex services >>>will >>>have to work in H.323. This allows H.245 and H.225 to go completely >>>independently and in parallel, and the poor CONNECT message can just be >>>the >>>final word saying "you're on the air". Logically, if you need H.245 for >>>your call, this is the fastest possible way to get it. >>> >>>You may be thinking, quite correctly "If Scott thinks that the next >>>generation of terminals is going to do H.245 before CONNECT then why in >>>the >>>world does he need FastStart?" This is a good question, but it has a >>>very >>>good answer (I'll bet you thought I would have one....) >>> >>>We perceive an absolute market requirement for the shortest, simplest, >>>fastest, lightweightest, stupidest kind of Internet Telephones, and >>>that a >>>system that cannot support such devices will be very vunerable to >>>attack >>>from competing systems that can. It is very important to be able to >>>build >>>"dumb telephone systems" as well as "intelligent ones". FastStart is a >>>great step forward for dumbness ;-). (sorry Jim). >>> >>>At the risk of repeating myself, even in the some of the scenarios Pete >>>mentions it is useful to use FastStart. It allows a gatekeeper to >>>answer >>>immediately (i.e. "as fast as possible") and reassure the caller that >>>although the system may take a few seconds to find the user and >>>negotiate, >>>this is being done. This is the way to port standard call center stuff >>>to >>>IP seamlessly. The "call center gatekeeper" answers in one round trip >>>with >>>FastStart, sends a CONNECT, and then the ACD-function starts up the >>>real >>>H.245 as part of its thing while blasting out music on hold. >>> >>>The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >>>CONNECT message. We believe that we in the H.323 community should do >>>everything possible to return the CONNECT message to its true Q.931 >>>meaning >>>of "you have end to end bearer NOW." The little fight over billing we >>>had >>>at SunRiver is only one of the issues. It is very confusing for people >>>and >>>systems to have CONNECT all of a sudden mean something else. Granted, >>>there >>>is nothing that we can do now about v1 systems, but we believe very >>>deeply >>>that every effort should be made to delay CONNECT until all >>>media/location >>>decisions are over, there is bearer, and talking/seeing can occur. This >>>is >>>what the CONNECT message is about. The fact is that it is possible to >>>do >>>H.245 upon CallSetup, and the system can take as long as it needs to do >>>"intelligence" before the CONNECT message. Remember that these >>>intelligent >>>things take some time, at least a few round trips, and in our >>>experience if >>>you start doing them you have plenty of time to negotiate media via >>>H.245. >>> >>>I hope that it is clearer now why I have a problem with any scheme to >>>"delay establishing media until after the CONNECT message." This is a >>>bad >>>habit that we need to end. I hope too that it is clearer why I like the >>>FastStart. We need good old dumb "black telephone service." If you >>>have >>>been listening to the IETF noise over this issue, you will know that >>>this >>>attack on H.323 is being taken seriously by many customers. Fast Start >>>answers that attack and adds a real new feature to H.323. >>> >>>Sincerely, >>> >>>Scott Petrack >>> > >

2 4

Re: Pete Cordell's FastStart issues
by Jim Toga 22 Dec '97

22 Dec '97

Pete, After landing back in the office for more than one day straight, here are my comments... sorry about the delay. jimt. At 04:22 PM 12/10/97 -0000, Pete Cordell wrote: >Jim, > >You've definitely captured the core technical functionality required. I >was hoping to get you to appreciate the big picture behind the technical >details so that you can understand why they are so important. It's at >this level we are perhaps not agreeing. But still, maybe that doesn't >matter so let's get on with looking for a technical solution. > >I note your comments below. Although I don't entirely agree with them >on all counts, one of the wonders of the English language is that >different people can get different meanings from the same piece of text. > So if we can agree that we understood different things from the text, >we can move on... > >Firstly I'm worried about sending multiple call proceedings/alertings to >an endpoint. Conceivably we could get the case that we receive a call >proceeding after alerting for example. This is definitely not valid >Q.931. Firstly I would like to see _anyone_ indicate that what we do in H.323 is valid Q.931..... We certainly borrowed a bunch of message formats, and some of the functionality, but I take my had off to anyone that has re-used an unmolested Q.931 stack :-) In any case, what I meant by passing changing/updated caps in Call Proceeding/Alerting message was not to have them be shuffled in order. Presumably the changes would occur during multiple Call Proceedings and when the final destination was found, maybe then again in conjunction with the Alerting message. >We could say that any endpoint that accepts fastStart should be >able to cope with this case, but this involves multiple modifications to >the Q.931/H.225 state machine which I feel is undesirable. A number of development engineers I have spoken with say this is a trivial issue, but as I said above I don't think it is a problem. >User >invitation and media establishment are in many respects orthogonal and >so making media negotiation conform to the invitation sequence is tying >one arm behind your back. Hmmm... I'm not sure how you know what media to send (from caller to callee) until an invitation has been accepted. The media from callee back to caller will have the same universe of choices no matter who the callee is. >What would be your comments if I suggested >moving the fastCaps stuff to the H323-UU-PDU field? A couple of things. I assume you mean that you want to turn the two field definitions into complete messages themselves. One problem is that this by definition increases the roundtrip times (thereby taking the 'fast' out of FastStart...) due to the fact that for Q.931 there can only be one message for each RFC1006 packet. Another issue is that if they are separate messages we run into complex and error prone issues with interactions of H.245. This would seem to be creating a 'new' H.245 within H.225.0 >This would allow us >to send the messages at any time (via FACILITY if necessary) without >affecting the Q.931 sequence and state. This should be OK as this is >what is being used for supplementary services. I'm not entirely sure what you mean by this. Supplementary service messages are indeed piggybacked in Facility messages, but the two that are currently defined change both the media and call connection state. If you're going to use Faciltiy messages to pass FastCaps at some 'later' time in the call sequence, I don't see how this saves any time over simply using H.245. > If this approach doesn't >work then we have a major problem, so any issues with it need to be >raised!!! > >I'm also thinking about how the gatekeeper will transfer the >capabilities through itself. It will have to decode the messages (e.g. >setup) so that it can find the relevant information. I assume the GK is doing some fancy footwork in order to do endpoint 'hunting' in any case. >It may then have >to change some of the fields before passing the message on. This will >mean re-encoding the message. If there is a mis-match in the version of >Capability supported by the endpoint and the gatekeeper then capability >information will get lost in this process. Why is does the GK have any capabilities? It isn't a calleable entity... Gateways on the other hand will have to do this, but they have always been in the business of en/decoding the connection messages. >This means that endpoints >will not be able to achieve end-to-end negotiation of caps, and any new >codecs added by vendors will not be usable in this configuration. I fail to see where you draw this conclusion from. You seem to want to put the GK in the middle of all of this, exert great control, and remain completely ignorant of any of the signalling that is occuring. There is no reason why the endpoints can not exchange their FastCaps end to end unless the GK blocks them (as it can for any other exchange in the GK routed model). >As I >envision faster evolution in the endpoint arena this seems a very real >proposition. To get around this problem it may be best to include the >capability information as an OCTET STRING. This allows the gatekeeper >to look at it, So which do you want, to have it be opaque to the GK or to have the GK be able to interpret it? As new codecs are developed (as we all hope they will be :-) ) there are the same two choices for FastCaps as with the standard H.245 negotiation mechanism. The first is to get a specific codepoint (and RTP payload format) defined for the codec. The second method is to use the nonStandardCap to signal it. This might be used for a specific vendor or a group of vendors by agreeement. >but also allows it to insert the information into an >outgoing message without having to have decoded it and re-encoded it >(i.e. it is just a copy operation) and so no information is lost. The GK can _always_ simply pass/copy the messages if it does not desire to provide some extended services during the call establishment (whatever they might be). >I hope this moves us forward and not backwards!!! I look forward to >your comments, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > [Remainder of this message is snipped] ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Proposal for changes to CHAT protocols T.134 and T.140
by Mark Duckworth 19 Dec '97

19 Dec '97

I'm looking for comments on the enclosed proposal, which I would like to see incorporated into the T.134 and T.140 recommendations before decision in Geneva next month. Also, a couple months ago Toby Nixon raised the issue "why do we need H.chat when we have T.chat?", but I didn't see any discussion on the ITU-SG16 reflector. I think we don't need H.chat in an H.323 environment, for all the reasons Toby mentioned. Mark Duckworth duckworthm(a)pictel.com 1. Introduction This document proposes specific modifications to T.134 and T.140. The intent is to clarify the usage of T.140 in the T.134 multipoint environment and to fix the ASN.1. 2. Proposed changes to T.140 There is no need to have the light and enhanced profiles in a multipoint session. Several enhanced commands are specifically not allowed in multipoint, and the other commands can be safely ignored, so the proposal is to eliminate the distinction between light and enhanced. The entire text of section 9, profile and multipoint considerations, should be replaced with the following: In point-to-point sessions, communication should be limited to what is supported in the highest common profile. In multipoint sessions it is not desired that a single node with a low profile can dictate the level of the communication used. Therefore the following principles shall be adopted: In a point-to-point session, the highest common profile shall be used. ENHANCED is regarded higher than LIGHT. In a multipoint session, there is no distinction between enhanced and light profiles. A multipoint terminal may send commands from the ENHANCED set of protocol elements. A multipoint terminal shall be capable of ignoring protocol elements it does not support. The following protocol elements shall be sent only to a specific node and thus not used in multipoint sessions: "Unsupported request", "Check status", "Status report", "Resynchronize", "Indicate ENHANCED profile". All other protocol elements shall be distributed to all participants in the session. A multipoint session includes any session in a multipoint capable environment (such as T.134), even if only two terminals are involved at a given time. 3. Proposed changes to T.134 3.1 CHAT Concepts The description of the diagram in section 5.1, CHAT Concepts, is misleading. The second bullet item, which states "CHATE C acts as an MCU, distributing the CHATPDUs among the CHATEs" should be replaced with the following: "The MCS provider in the node with CHATE C acts as an MCU, distributing the CHATPDUs among the CHATEs". 3.2 Conducted mode operation The behaviour of a T.134 APE should be restricted in a conducted mode conference. The following text should be added at the end of section 7, Use of GCC: When a session is in conducted mode, a CHATE may be restricted from sending data, depending on the GCC conducted-mode permission mechanism. If the node is given GCC conducted-mode permission, then a CHATE may send any type of ChatPDU. If the node is not given GCC conducted-mode permission, then a CHATE shall not send any type of ChatPDU. 3.3 Non-standard extensions Text should be added at the end of section 8.3, CHATPDU Formats: A ChatPDU can contain non standard information using the chatNonStandardPDU choice. This uses the H221NonStandardIdentifier to allow an implementation to use non-standard information without conflicting with any other implementation's non-standard information. If a terminal receives a ChatNonStandardPDU it doesn't understand, it shall ignore the PDU. 3.4 ASN.1 Unused types are removed, and a non-standard PDU choice is added to allow proprietary extensions. The entire section 9.1, ASN.1 Definition, should be replaced with the following: --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- Begin CHAT Definitions -- -- The following base mode ASN.1 definitions are encoded using the BASIC -- ALIGNED variant of the Packed Encoding Rules of ITU-T Recommendation -- X.691. -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| CHAT-PROTOCOL DEFINITIONS AUTOMATIC TAGS ::= BEGIN -- NOTE: =============================================================== -- NOTE: All abstract types defined shall be exported -- NOTE: =============================================================== -- H221NonStandardIdentifer -- Used to specify non-standard objects using H.221 numbering. -- The first four octets shall designate country code and -- manufacturer code, assigned as specified in -- Annex A/H.221 for NS-cap and NS-comm. H221NonStandardIdentifier ::= OCTET STRING (SIZE (4..255)) Key ::= CHOICE -- Identifier of a standard or non-standard object { object OBJECT IDENTIFIER, h221NonStandard H221NonStandardIdentifier } -- NonStandardParameter -- Used to specify non-standard parameters. This includes a -- data field which may be used to fill in parameter values -- of the type indicated by the NonStandardIdentifier NonStandardParameter ::= SEQUENCE { key Key, value OCTET STRING OPTIONAL } ChatString ::= GeneralString (SIZE (0..255)) -- Chat Protocol String --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- Begin CHATPDU Definitions -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ChatentryPDU ::= SEQUENCE { chatString ChatString, ... } ChatNonStandardPDU ::= SEQUENCE { nonStandardTransaction NonStandardParameter, ... } ChatPDU ::= CHOICE { chatentryPDU ChatentryPDU, chatNonStandardPDU ChatNonStandardPDU, ... } --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- End CHAT Definitions -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| END 3.5 Object Identifier Typographic errors in the object identifier should be fixed, so it conforms to Recommendation X.680. The object identifier in Annex C is given as: {itu recommendation T.134 version 1} This should be replaced with: {itu-t recommendation t 134 version(0) 1} END

2 1

H.bmultipoint drift
by Li Yan 19 Dec '97

19 Dec '97

Dear Mr. Harasaki, Mr. Okubo, and other Q.12/16 experts, Sorry I could not get back to you earlier. Business trip and works have kept me very busy. Now I am on vacation and I finally got chance to go over the H.bmultipoint drift. I have several questions/comments listed below: 1. On page 9, Figure 3, blockdiagram of a Multipoint Control Unit, 1a) Does MC talk to MR too? There is no connection between the two in the diagram. 1b) Should Call Control function be distributed between MC and Network Interface? 1c) There should have multiple inputs/outputs to/from Audio Processing Unit, Video Processing Unit, and Data Processing unit. 2. By checking Chapter 5 and Chapter 7, I could not tell the difference. I understand you want Chapter 5 to be a general system description while chapter 7 to be MCU specifics. But if H.bmultipoint only deal with multipoint with MCU, there is no difference between the two. Or the two chapters should be merged into one because the general system is MCU. 3. In general, multipoint includes multipoint with MCU (centralized) and multipoint without MCU (distributed). If Chapter 5 includes configuration on multipoint without MCU, then there is difference between Chapter 5 and 7, where Chapter 5 is a general system and Chapter 7 is multipoint with MCU. We can make multipoint without MCU for further study since we agreed on Sunriver meeting that we would focus on tightly-coupled multipoint with MCU. In my mind, Chapter 5 can be like 5.1 MC 5.2 MP 5.3 MR 5.4 MCU 5.5 Multipoint configurations 5.5.1 Multipoint without MCU (Text can be found in F.702) 5.5.2 Multipoint with MCU (Text can be found in F.702) *** Four types of VC connection configurations for Centralized MCU. ( Should this be moved to Chapter 7 ??) Chapter 7: (7.x: VC connection configurations for MCU??) 7.1, 7.2, 7.3 More detailed description about MC, MP, and MR? 7.4 Clock synchronization 7.5 MCU-MCU interconnections---- This should include diagrams to show multi-MCU configurations (from H.231 or F.702) 4. On 5.6, we only listed four H.245 commands/procedures. I think we need more to support multipoint. Should we list they all or we are not really sure what we really want? 5. I like the break up between the basic procedure and advanced procedures. But do they still belong to Chapter 6? Hope these will not be too late or cause too much confusion. Thanks. Li lyan(a)lucent.com Lucent Technologies

1 0

Re: Analysing fast start
by Pete Cordell 19 Dec '97

19 Dec '97

Linh, Another benefit of using a single TCP connection is that it makes scaleable gatekeeper farms much easier to implement. For example, you can get boxes that will sit in front of multiple HTTP servers to spread the load. These use some algorithm to distribute the various TCP connections. For H.323, it is likely that with two TCP connections, the Q.931 TCP connection and the H.245 TCP connection would end up on different machines. This makes the design difficult if not impossible! Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Hong Linh Truong[SMTP:hlt@ZURICH.IBM.COM] >Sent: 19 December 1997 10:38 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Analysing fast start > >Without having analysed all the details, I believe Pete's fast start >approach has the following advantages compared to the one currently >included in H.323 V2: > Having only one TCP connection instead of two not only makes H.323 >more > scalable, it also simplifies the coordination and the handling of >race > conditions between Q.931 and H.245. > It allows re-use of codes written for the ad-hoc conferencing, >because > it does not change anything to the H.245 procedures, it just moves >them > to the H.225 control channel. >Linh > >------------------------------------------------------------ >Hong Linh Truong >IBM Zurich Research Lab. SMTP: hlt(a)zurich.ibm.com >Saeumerstr. 4 Notes: Hong Linh >Truong/Zurich/IBM@Zurich@IBM_INTERNAL >CH-8803 Rueschlikon >Switzerland phone: +41 1 724 8434 fax: +41 1 724 8955 >

1 0

Re: Fast Start issues
by Pete Cordell 19 Dec '97

19 Dec '97

Bob, I don't know how I can say this differently, but I am definitely not saying that we should always wait for CONNECT for connecting through media. As you (and Tom) have said there are very good reasons for connecting it through early. HOWEVER, there are situations where the gatekeeper needs the CONNECT from an endpoint before the media is connected through, and we need some flexibility here. This is a very complicated area (which in my eyes at least has quite a simple solution) and the band-aid fix that we have is going to come back a bite us in the future. As this will be my last message this year, my feeling is that we are shooting H.323 in the foot with this fix. It makes clients heavier, it is not flexible enough, and hasn't been thought through properly. To expand on the latter, there is no procedures for handling both the called and calling endpoints trying to start H.245 at the same time. Gatekeepers will have a hard time passing through the cap sets if the versions of the Capability structure they are not the same. Seasons Greetings, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Callaghan, Robert[SMTP:Robert.Callaghan@SIEMENSCOM.COM] >Sent: 18 December 1997 18:01 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Fast Start issues > >Pete, > >Please do no minimize the requirement for a bearer path cut-through >before CONNECT. In the PBX world, the path is fully cut-through before >the ALERT message. That allows for the transmission of progress tones >(Alerting, Busy, etc.) and announcements. The Public network, because >of fraud control, fully cuts-through all nodes except for the last node >in the Public Network. Here a half path is cut-through. This also >allows for progress tones and announcements. The side benefit is that >the "Hello" can transverse the network while the path is being >completed. The specified "100 ms" is from the answer signal (off-hook) >of the terminal to the complete path cut-through. (This covers more >delays that the time between the network CONNECT signal and the >cut-through.) In the switched network this is very difficult, when >even >a portion of the path is left open. > >As I stated in Sun River, many users will allow for 5 seconds between >answering the telephone and abandoning the call when there is no >response. This is substantially below the 15 to 20 seconds time for an >H.323v1 terminal. This is based on informal human factors surveys. > >Solutions include the setup, negotiation, and path establishment based >on the SETUP message; or using the Fast Start setup. In either case, >the receiving end should fully establish the path before alerting the >terminal or, for gateways, sending the call to the switched circuit >network (PSTN). > >I don't understand the concern over obtaining enhanced operation with >terminals that do not implement the "enhancing" procedures. This is a >fact. A H.323v1 terminal cannot support this operation. If enhanced >procedures are required, it makes no difference whether it is "Fast >Start" or your proposal. To repeat, in order to get enhanced services, >enhanced procedures are required; however, they are optional for the >terminal providers. There is no solution to this dilemma. > >Bob > >-------------------------------------- >Robert Callaghan >Siemens Business Communication Systems >Email: Robert.Callaghan(a)Siemenscom.com >Tel: +1.561.997.3756 >FAX: +1.561.997.3403 > >>-----Original Message----- >>From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >>Sent: Thursday, December 18, 1997 8:45 AM >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Re: Fast Start issues >> >>Scott, >> >>Thanks for your lengthy reply... >> >>What I was hoping to indicate was that for certain call scenarios you >>want media established before CONNECT, but for other scenarios this is >>not possible. >> >>A situation where you have to send CONNECT before the media is >>negotiated is when multiple phones are rang and the first one is >>answered. There are probably others. >> >>The point is that some flexibility is required on this point. >> >>I agree with your comments about mandating that fast start should allow >>for H.245 to be started at any time. I didn't contest the wording as it >>seemed to me that whatever wording was in the standard, if it suited a >>vendor they could quite easily ignore any request to do fast start. >>This would total destroy any attempt to deliver some services and is >>hence a problem for us. >> >>I'm also interested that you state that you are looking for light-weight >>systems that do not use H.245. Firstly this is in conflict with the >>wording at the moment. Secondly, it is only an illusion of a simpler >>implementation, as much of H.245 is being copied into H.225 (work out >>how much of H.245 is included into H.225 just by referencing >>Capability). >> >>As to how CONNECT works in the switched network, it seems that the >>called endpoint sends CONNECT before the bearer path is in place. The >>final switch will connect the bearer when it receives CONNECT. The >>CONNECT is then forwarded. The point is that the CONNECT is sent before >>the bearer is connected through, but the bearer is connect through by >>the time CONNECT is received. This is difficult to emulate in our >>environment. You can't just delay the CONNECT in the gatekeeper until >>the media is established because the user is concerned with the time >>from 'picking up the handset' to when they can speak and are not >>concerned with how this relates to the timing of the CONNECT message. >>Some one said the switched network delay in this instance is less than >>100ms. >> >>Regards, >> >>Pete >>================================= >>Pete Cordell >>BT Labs >>E-Mail: pete.cordell(a)bt-sys.bt.co.uk >>Tel: +44 1473 646436 >>Fax: +44 1473 645499 >>================================= >> >> >>>---------- >>>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>>Sent: 18 December 1997 01:52 >>>To: ITU-SG16(a)MAILBAG.INTEL.COM >>>Subject: Fast Start issues >>> >>>Friends, and especially Pete, >>> >>>It really does seem to me that it is possible to get everyone happy. I >>>would like to try and convince you (Pete) that: >>> a. you can get EXACTLY what you need, in the fastest, most correct >>>way >>>possible, right now, and >>> b. Intel's FastStart is really an important and useful thing as is >>>for >>>H.323. >>> >>>It is possible that a single sentence needs to be added to the >>>FastStart >>>text (see below in the paragraph starting "The thing that you >>>require..."). >>>But mainly I believe that there is a small misunderstanding going on, >>>which >>>is main the source of the problem. >>> >>>Pete, to get this extra "intelligence" you want, I believe that in most >>>cases you must use gatekeeper routed signalling. The called gatekeeper, >>>acting as a proxy for the called user, must send the H.245 port in the >>>CallProceeding message, H.245 negotiation must be used, and the CONNECT >>>message must come at the end, after all location/media negotiations are >>>over and media is available. >>> >>>I say "in most cases" because there are some cases where you will >>>probably >>>choose to do some intelligence in the LRQ phase, before the CallSetup >>>is >>>sent. In these cases it might be possible to know that the CallSetup >>>message is really being sent to the correct Terminal, and so you can >>>then >>>use FastStart to that Terminal. There are also other cases where you >>>may >>>choose to do FastStart with to the user's gatekeeper, have the >>>gatekeeper >>>play out a prompt saying something like "we are looking for your user >>>now", >>>have the gatekeeper do H.245 negotiation with the caller on behalf of >>>the >>>callee, and in the end establish a new media channel to the final >>>negotiated endpoint, breaking the original media channel negotiated >>>with >>>the gatekeeper in the FastStart. All this can be done now by using a >>>combination of FastStart and "classic" H.323 signalling. >>> >>>The "misunderstanding" I was alluding to earlier is this: you are >>>correct >>>that most endpoints until now unfortunately did CONNECT before media >>>negotiation. This is a very unfortunate breaking of Q.931 semantics >>>which >>>could have been avoided, and we should try hard to return to the normal >>>situation where CONNECT is sent only at the end of the entire call >>>establishment procedure. My problem is with the 2nd requirement you >>>gave in >>>an earlier posting: >>> >>>>we want to delay establishing media until after >>>>CONNECT so that the gatekeeper can do some intelligent stuff. >>> >>>I definitely DON'T want to delay establishing media until after >>>CONNECT. >>>And I claim that this is NOT needed for the gatekeeper to do some >>>intelligent stuff. >>> >>>The thing that you require, that is not quite there in the current >>>FastStart proposal, is that "even if a connection is made using >>>FastStart, >>>it shall be possible for either endpoint to start H.245 negotiation at >>>any >>>point in the conversation". I would be willing to go with this in the >>>spirit of compromise. (although personally I feel that such "shalls" >>>are >>>about as strong as "An H.uman endpoint shall not eat pork." Lot's of >>>people >>>who claim "Bible compliance" do not follow this shall, and somehow the >>>world continues to interoperate...) >>> >>>We at VocalTec, as part of our CMA work, support many of the scenarios >>>you >>>talk about, and we do it quite quickly (we think as quickly as >>>logically >>>possible in fact). Some of them require H.245, some require gatekeeper >>>routed signalling, some can be done with FastStart alone. >>> >>>I want to go on record saying that we DEFINITELY want to encourage >>>finishing the H.245 negotiation before CONNECT if it happens. This >>>function >>>is in H.323 now, and it is *the thing* that allows us to do the >>>scenarios >>>that Pete seems to want. We believe that this is how complex services >>>will >>>have to work in H.323. This allows H.245 and H.225 to go completely >>>independently and in parallel, and the poor CONNECT message can just be >>>the >>>final word saying "you're on the air". Logically, if you need H.245 for >>>your call, this is the fastest possible way to get it. >>> >>>You may be thinking, quite correctly "If Scott thinks that the next >>>generation of terminals is going to do H.245 before CONNECT then why in >>>the >>>world does he need FastStart?" This is a good question, but it has a >>>very >>>good answer (I'll bet you thought I would have one....) >>> >>>We perceive an absolute market requirement for the shortest, simplest, >>>fastest, lightweightest, stupidest kind of Internet Telephones, and >>>that a >>>system that cannot support such devices will be very vunerable to >>>attack >>>from competing systems that can. It is very important to be able to >>>build >>>"dumb telephone systems" as well as "intelligent ones". FastStart is a >>>great step forward for dumbness ;-). (sorry Jim). >>> >>>At the risk of repeating myself, even in the some of the scenarios Pete >>>mentions it is useful to use FastStart. It allows a gatekeeper to >>>answer >>>immediately (i.e. "as fast as possible") and reassure the caller that >>>although the system may take a few seconds to find the user and >>>negotiate, >>>this is being done. This is the way to port standard call center stuff >>>to >>>IP seamlessly. The "call center gatekeeper" answers in one round trip >>>with >>>FastStart, sends a CONNECT, and then the ACD-function starts up the >>>real >>>H.245 as part of its thing while blasting out music on hold. >>> >>>The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >>>CONNECT message. We believe that we in the H.323 community should do >>>everything possible to return the CONNECT message to its true Q.931 >>>meaning >>>of "you have end to end bearer NOW." The little fight over billing we >>>had >>>at SunRiver is only one of the issues. It is very confusing for people >>>and >>>systems to have CONNECT all of a sudden mean something else. Granted, >>>there >>>is nothing that we can do now about v1 systems, but we believe very >>>deeply >>>that every effort should be made to delay CONNECT until all >>>media/location >>>decisions are over, there is bearer, and talking/seeing can occur. This >>>is >>>what the CONNECT message is about. The fact is that it is possible to >>>do >>>H.245 upon CallSetup, and the system can take as long as it needs to do >>>"intelligence" before the CONNECT message. Remember that these >>>intelligent >>>things take some time, at least a few round trips, and in our >>>experience if >>>you start doing them you have plenty of time to negotiate media via >>>H.245. >>> >>>I hope that it is clearer now why I have a problem with any scheme to >>>"delay establishing media until after the CONNECT message." This is a >>>bad >>>habit that we need to end. I hope too that it is clearer why I like the >>>FastStart. We need good old dumb "black telephone service." If you >>>have >>>been listening to the IETF noise over this issue, you will know that >>>this >>>attack on H.323 is being taken seriously by many customers. Fast Start >>>answers that attack and adds a real new feature to H.323. >>> >>>Sincerely, >>> >>>Scott Petrack >>> >

1 0

Re: Analysing fast start
by Hong Linh Truong 19 Dec '97

19 Dec '97

Without having analysed all the details, I believe Pete's fast start approach has the following advantages compared to the one currently included in H.323 V2: Having only one TCP connection instead of two not only makes H.323 more scalable, it also simplifies the coordination and the handling of race conditions between Q.931 and H.245. It allows re-use of codes written for the ad-hoc conferencing, because it does not change anything to the H.245 procedures, it just moves them to the H.225 control channel. Linh ------------------------------------------------------------ Hong Linh Truong IBM Zurich Research Lab. SMTP: hlt(a)zurich.ibm.com Saeumerstr. 4 Notes: Hong Linh Truong/Zurich/IBM@Zurich@IBM_INTERNAL CH-8803 Rueschlikon Switzerland phone: +41 1 724 8434 fax: +41 1 724 8955

1 0

Re: Potential Addressing Issue
by Gene Schroeder 18 Dec '97

18 Dec '97

I believe this is a general problem for protocols that carry IP addresses in the application level, like FTP. I would think an H.323 proxy would be needed in this kind of environment. Gene Schroeder Lucent ---------- > From: Tom Taylor <Tom.Taylor.taylor(a)NT.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Potential Addressing Issue > Date: Thursday, December 18, 1997 12:48 PM > > I was going over my notes for the IETF MMUSIC session last week, and > came across an item which may be an issue for H.323. Thanks to the > presence of Network Address Translation (NAT) in the net, an endpoint > doesn't necessarily know its true network address. (NAT boxes translate > between local addresses and public ones invisibly to the hosts > concerned.) Thus the address an H.323 endpoint sends out during > registration with the Gatekeeper may be bogus.

1 0

Re: Fast Start issues
by Callaghan, Robert 18 Dec '97

18 Dec '97

Pete, Please do no minimize the requirement for a bearer path cut-through before CONNECT. In the PBX world, the path is fully cut-through before the ALERT message. That allows for the transmission of progress tones (Alerting, Busy, etc.) and announcements. The Public network, because of fraud control, fully cuts-through all nodes except for the last node in the Public Network. Here a half path is cut-through. This also allows for progress tones and announcements. The side benefit is that the "Hello" can transverse the network while the path is being completed. The specified "100 ms" is from the answer signal (off-hook) of the terminal to the complete path cut-through. (This covers more delays that the time between the network CONNECT signal and the cut-through.) In the switched network this is very difficult, when even a portion of the path is left open. As I stated in Sun River, many users will allow for 5 seconds between answering the telephone and abandoning the call when there is no response. This is substantially below the 15 to 20 seconds time for an H.323v1 terminal. This is based on informal human factors surveys. Solutions include the setup, negotiation, and path establishment based on the SETUP message; or using the Fast Start setup. In either case, the receiving end should fully establish the path before alerting the terminal or, for gateways, sending the call to the switched circuit network (PSTN). I don't understand the concern over obtaining enhanced operation with terminals that do not implement the "enhancing" procedures. This is a fact. A H.323v1 terminal cannot support this operation. If enhanced procedures are required, it makes no difference whether it is "Fast Start" or your proposal. To repeat, in order to get enhanced services, enhanced procedures are required; however, they are optional for the terminal providers. There is no solution to this dilemma. Bob -------------------------------------- Robert Callaghan Siemens Business Communication Systems Email: Robert.Callaghan(a)Siemenscom.com Tel: +1.561.997.3756 FAX: +1.561.997.3403 >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, December 18, 1997 8:45 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Fast Start issues > >Scott, > >Thanks for your lengthy reply... > >What I was hoping to indicate was that for certain call scenarios you >want media established before CONNECT, but for other scenarios this is >not possible. > >A situation where you have to send CONNECT before the media is >negotiated is when multiple phones are rang and the first one is >answered. There are probably others. > >The point is that some flexibility is required on this point. > >I agree with your comments about mandating that fast start should allow >for H.245 to be started at any time. I didn't contest the wording as it >seemed to me that whatever wording was in the standard, if it suited a >vendor they could quite easily ignore any request to do fast start. >This would total destroy any attempt to deliver some services and is >hence a problem for us. > >I'm also interested that you state that you are looking for light-weight >systems that do not use H.245. Firstly this is in conflict with the >wording at the moment. Secondly, it is only an illusion of a simpler >implementation, as much of H.245 is being copied into H.225 (work out >how much of H.245 is included into H.225 just by referencing >Capability). > >As to how CONNECT works in the switched network, it seems that the >called endpoint sends CONNECT before the bearer path is in place. The >final switch will connect the bearer when it receives CONNECT. The >CONNECT is then forwarded. The point is that the CONNECT is sent before >the bearer is connected through, but the bearer is connect through by >the time CONNECT is received. This is difficult to emulate in our >environment. You can't just delay the CONNECT in the gatekeeper until >the media is established because the user is concerned with the time >from 'picking up the handset' to when they can speak and are not >concerned with how this relates to the timing of the CONNECT message. >Some one said the switched network delay in this instance is less than >100ms. > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>Sent: 18 December 1997 01:52 >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Fast Start issues >> >>Friends, and especially Pete, >> >>It really does seem to me that it is possible to get everyone happy. I >>would like to try and convince you (Pete) that: >> a. you can get EXACTLY what you need, in the fastest, most correct >>way >>possible, right now, and >> b. Intel's FastStart is really an important and useful thing as is >>for >>H.323. >> >>It is possible that a single sentence needs to be added to the >>FastStart >>text (see below in the paragraph starting "The thing that you >>require..."). >>But mainly I believe that there is a small misunderstanding going on, >>which >>is main the source of the problem. >> >>Pete, to get this extra "intelligence" you want, I believe that in most >>cases you must use gatekeeper routed signalling. The called gatekeeper, >>acting as a proxy for the called user, must send the H.245 port in the >>CallProceeding message, H.245 negotiation must be used, and the CONNECT >>message must come at the end, after all location/media negotiations are >>over and media is available. >> >>I say "in most cases" because there are some cases where you will >>probably >>choose to do some intelligence in the LRQ phase, before the CallSetup >>is >>sent. In these cases it might be possible to know that the CallSetup >>message is really being sent to the correct Terminal, and so you can >>then >>use FastStart to that Terminal. There are also other cases where you >>may >>choose to do FastStart with to the user's gatekeeper, have the >>gatekeeper >>play out a prompt saying something like "we are looking for your user >>now", >>have the gatekeeper do H.245 negotiation with the caller on behalf of >>the >>callee, and in the end establish a new media channel to the final >>negotiated endpoint, breaking the original media channel negotiated >>with >>the gatekeeper in the FastStart. All this can be done now by using a >>combination of FastStart and "classic" H.323 signalling. >> >>The "misunderstanding" I was alluding to earlier is this: you are >>correct >>that most endpoints until now unfortunately did CONNECT before media >>negotiation. This is a very unfortunate breaking of Q.931 semantics >>which >>could have been avoided, and we should try hard to return to the normal >>situation where CONNECT is sent only at the end of the entire call >>establishment procedure. My problem is with the 2nd requirement you >>gave in >>an earlier posting: >> >>>we want to delay establishing media until after >>>CONNECT so that the gatekeeper can do some intelligent stuff. >> >>I definitely DON'T want to delay establishing media until after >>CONNECT. >>And I claim that this is NOT needed for the gatekeeper to do some >>intelligent stuff. >> >>The thing that you require, that is not quite there in the current >>FastStart proposal, is that "even if a connection is made using >>FastStart, >>it shall be possible for either endpoint to start H.245 negotiation at >>any >>point in the conversation". I would be willing to go with this in the >>spirit of compromise. (although personally I feel that such "shalls" >>are >>about as strong as "An H.uman endpoint shall not eat pork." Lot's of >>people >>who claim "Bible compliance" do not follow this shall, and somehow the >>world continues to interoperate...) >> >>We at VocalTec, as part of our CMA work, support many of the scenarios >>you >>talk about, and we do it quite quickly (we think as quickly as >>logically >>possible in fact). Some of them require H.245, some require gatekeeper >>routed signalling, some can be done with FastStart alone. >> >>I want to go on record saying that we DEFINITELY want to encourage >>finishing the H.245 negotiation before CONNECT if it happens. This >>function >>is in H.323 now, and it is *the thing* that allows us to do the >>scenarios >>that Pete seems to want. We believe that this is how complex services >>will >>have to work in H.323. This allows H.245 and H.225 to go completely >>independently and in parallel, and the poor CONNECT message can just be >>the >>final word saying "you're on the air". Logically, if you need H.245 for >>your call, this is the fastest possible way to get it. >> >>You may be thinking, quite correctly "If Scott thinks that the next >>generation of terminals is going to do H.245 before CONNECT then why in >>the >>world does he need FastStart?" This is a good question, but it has a >>very >>good answer (I'll bet you thought I would have one....) >> >>We perceive an absolute market requirement for the shortest, simplest, >>fastest, lightweightest, stupidest kind of Internet Telephones, and >>that a >>system that cannot support such devices will be very vunerable to >>attack >>from competing systems that can. It is very important to be able to >>build >>"dumb telephone systems" as well as "intelligent ones". FastStart is a >>great step forward for dumbness ;-). (sorry Jim). >> >>At the risk of repeating myself, even in the some of the scenarios Pete >>mentions it is useful to use FastStart. It allows a gatekeeper to >>answer >>immediately (i.e. "as fast as possible") and reassure the caller that >>although the system may take a few seconds to find the user and >>negotiate, >>this is being done. This is the way to port standard call center stuff >>to >>IP seamlessly. The "call center gatekeeper" answers in one round trip >>with >>FastStart, sends a CONNECT, and then the ACD-function starts up the >>real >>H.245 as part of its thing while blasting out music on hold. >> >>The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >>CONNECT message. We believe that we in the H.323 community should do >>everything possible to return the CONNECT message to its true Q.931 >>meaning >>of "you have end to end bearer NOW." The little fight over billing we >>had >>at SunRiver is only one of the issues. It is very confusing for people >>and >>systems to have CONNECT all of a sudden mean something else. Granted, >>there >>is nothing that we can do now about v1 systems, but we believe very >>deeply >>that every effort should be made to delay CONNECT until all >>media/location >>decisions are over, there is bearer, and talking/seeing can occur. This >>is >>what the CONNECT message is about. The fact is that it is possible to >>do >>H.245 upon CallSetup, and the system can take as long as it needs to do >>"intelligence" before the CONNECT message. Remember that these >>intelligent >>things take some time, at least a few round trips, and in our >>experience if >>you start doing them you have plenty of time to negotiate media via >>H.245. >> >>I hope that it is clearer now why I have a problem with any scheme to >>"delay establishing media until after the CONNECT message." This is a >>bad >>habit that we need to end. I hope too that it is clearer why I like the >>FastStart. We need good old dumb "black telephone service." If you >>have >>been listening to the IETF noise over this issue, you will know that >>this >>attack on H.323 is being taken seriously by many customers. Fast Start >>answers that attack and adds a real new feature to H.323. >> >>Sincerely, >> >>Scott Petrack >>

1 0

Potential Addressing Issue
by Tom Taylor 18 Dec '97

18 Dec '97

I was going over my notes for the IETF MMUSIC session last week, and came across an item which may be an issue for H.323. Thanks to the presence of Network Address Translation (NAT) in the net, an endpoint doesn't necessarily know its true network address. (NAT boxes translate between local addresses and public ones invisibly to the hosts concerned.) Thus the address an H.323 endpoint sends out during registration with the Gatekeeper may be bogus.

1 0

Re: Fast Start issues
by Tom Taylor 18 Dec '97

18 Dec '97

I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing? >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, December 18, 1997 8:45 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Fast Start issues > >Scott, > >Thanks for your lengthy reply... > >What I was hoping to indicate was that for certain call scenarios you >want media established before CONNECT, but for other scenarios this is >not possible. > >A situation where you have to send CONNECT before the media is >negotiated is when multiple phones are rang and the first one is >answered. There are probably others. > >The point is that some flexibility is required on this point. > >I agree with your comments about mandating that fast start should allow >for H.245 to be started at any time. I didn't contest the wording as it >seemed to me that whatever wording was in the standard, if it suited a >vendor they could quite easily ignore any request to do fast start. >This would total destroy any attempt to deliver some services and is >hence a problem for us. > >I'm also interested that you state that you are looking for light-weight >systems that do not use H.245. Firstly this is in conflict with the >wording at the moment. Secondly, it is only an illusion of a simpler >implementation, as much of H.245 is being copied into H.225 (work out >how much of H.245 is included into H.225 just by referencing >Capability). > >As to how CONNECT works in the switched network, it seems that the >called endpoint sends CONNECT before the bearer path is in place. The >final switch will connect the bearer when it receives CONNECT. The >CONNECT is then forwarded. The point is that the CONNECT is sent before >the bearer is connected through, but the bearer is connect through by >the time CONNECT is received. This is difficult to emulate in our >environment. You can't just delay the CONNECT in the gatekeeper until >the media is established because the user is concerned with the time >from 'picking up the handset' to when they can speak and are not >concerned with how this relates to the timing of the CONNECT message. >Some one said the switched network delay in this instance is less than >100ms. > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>Sent: 18 December 1997 01:52 >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Fast Start issues >> >>Friends, and especially Pete, >> >>It really does seem to me that it is possible to get everyone happy. I >>would like to try and convince you (Pete) that: >> a. you can get EXACTLY what you need, in the fastest, most correct >>way >>possible, right now, and >> b. Intel's FastStart is really an important and useful thing as is >>for >>H.323. >> >>It is possible that a single sentence needs to be added to the >>FastStart >>text (see below in the paragraph starting "The thing that you >>require..."). >>But mainly I believe that there is a small misunderstanding going on, >>which >>is main the source of the problem. >> >>Pete, to get this extra "intelligence" you want, I believe that in most >>cases you must use gatekeeper routed signalling. The called gatekeeper, >>acting as a proxy for the called user, must send the H.245 port in the >>CallProceeding message, H.245 negotiation must be used, and the CONNECT >>message must come at the end, after all location/media negotiations are >>over and media is available. >> >>I say "in most cases" because there are some cases where you will >>probably >>choose to do some intelligence in the LRQ phase, before the CallSetup >>is >>sent. In these cases it might be possible to know that the CallSetup >>message is really being sent to the correct Terminal, and so you can >>then >>use FastStart to that Terminal. There are also other cases where you >>may >>choose to do FastStart with to the user's gatekeeper, have the >>gatekeeper >>play out a prompt saying something like "we are looking for your user >>now", >>have the gatekeeper do H.245 negotiation with the caller on behalf of >>the >>callee, and in the end establish a new media channel to the final >>negotiated endpoint, breaking the original media channel negotiated >>with >>the gatekeeper in the FastStart. All this can be done now by using a >>combination of FastStart and "classic" H.323 signalling. >> >>The "misunderstanding" I was alluding to earlier is this: you are >>correct >>that most endpoints until now unfortunately did CONNECT before media >>negotiation. This is a very unfortunate breaking of Q.931 semantics >>which >>could have been avoided, and we should try hard to return to the normal >>situation where CONNECT is sent only at the end of the entire call >>establishment procedure. My problem is with the 2nd requirement you >>gave in >>an earlier posting: >> >>>we want to delay establishing media until after >>>CONNECT so that the gatekeeper can do some intelligent stuff. >> >>I definitely DON'T want to delay establishing media until after >>CONNECT. >>And I claim that this is NOT needed for the gatekeeper to do some >>intelligent stuff. >> >>The thing that you require, that is not quite there in the current >>FastStart proposal, is that "even if a connection is made using >>FastStart, >>it shall be possible for either endpoint to start H.245 negotiation at >>any >>point in the conversation". I would be willing to go with this in the >>spirit of compromise. (although personally I feel that such "shalls" >>are >>about as strong as "An H.uman endpoint shall not eat pork." Lot's of >>people >>who claim "Bible compliance" do not follow this shall, and somehow the >>world continues to interoperate...) >> >>We at VocalTec, as part of our CMA work, support many of the scenarios >>you >>talk about, and we do it quite quickly (we think as quickly as >>logically >>possible in fact). Some of them require H.245, some require gatekeeper >>routed signalling, some can be done with FastStart alone. >> >>I want to go on record saying that we DEFINITELY want to encourage >>finishing the H.245 negotiation before CONNECT if it happens. This >>function >>is in H.323 now, and it is *the thing* that allows us to do the >>scenarios >>that Pete seems to want. We believe that this is how complex services >>will >>have to work in H.323. This allows H.245 and H.225 to go completely >>independently and in parallel, and the poor CONNECT message can just be >>the >>final word saying "you're on the air". Logically, if you need H.245 for >>your call, this is the fastest possible way to get it. >> >>You may be thinking, quite correctly "If Scott thinks that the next >>generation of terminals is going to do H.245 before CONNECT then why in >>the >>world does he need FastStart?" This is a good question, but it has a >>very >>good answer (I'll bet you thought I would have one....) >> >>We perceive an absolute market requirement for the shortest, simplest, >>fastest, lightweightest, stupidest kind of Internet Telephones, and >>that a >>system that cannot support such devices will be very vunerable to >>attack >>from competing systems that can. It is very important to be able to >>build >>"dumb telephone systems" as well as "intelligent ones". FastStart is a >>great step forward for dumbness ;-). (sorry Jim). >> >>At the risk of repeating myself, even in the some of the scenarios Pete >>mentions it is useful to use FastStart. It allows a gatekeeper to >>answer >>immediately (i.e. "as fast as possible") and reassure the caller that >>although the system may take a few seconds to find the user and >>negotiate, >>this is being done. This is the way to port standard call center stuff >>to >>IP seamlessly. The "call center gatekeeper" answers in one round trip >>with >>FastStart, sends a CONNECT, and then the ACD-function starts up the >>real >>H.245 as part of its thing while blasting out music on hold. >> >>The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >>CONNECT message. We believe that we in the H.323 community should do >>everything possible to return the CONNECT message to its true Q.931 >>meaning >>of "you have end to end bearer NOW." The little fight over billing we >>had >>at SunRiver is only one of the issues. It is very confusing for people >>and >>systems to have CONNECT all of a sudden mean something else. Granted, >>there >>is nothing that we can do now about v1 systems, but we believe very >>deeply >>that every effort should be made to delay CONNECT until all >>media/location >>decisions are over, there is bearer, and talking/seeing can occur. This >>is >>what the CONNECT message is about. The fact is that it is possible to >>do >>H.245 upon CallSetup, and the system can take as long as it needs to do >>"intelligence" before the CONNECT message. Remember that these >>intelligent >>things take some time, at least a few round trips, and in our >>experience if >>you start doing them you have plenty of time to negotiate media via >>H.245. >> >>I hope that it is clearer now why I have a problem with any scheme to >>"delay establishing media until after the CONNECT message." This is a >>bad >>habit that we need to end. I hope too that it is clearer why I like the >>FastStart. We need good old dumb "black telephone service." If you >>have >>been listening to the IETF noise over this issue, you will know that >>this >>attack on H.323 is being taken seriously by many customers. Fast Start >>answers that attack and adds a real new feature to H.323. >> >>Sincerely, >> >>Scott Petrack >>

1 0

Re: Fast Start issues
by Pete Cordell 18 Dec '97

18 Dec '97

Scott, Thanks for your lengthy reply... What I was hoping to indicate was that for certain call scenarios you want media established before CONNECT, but for other scenarios this is not possible. A situation where you have to send CONNECT before the media is negotiated is when multiple phones are rang and the first one is answered. There are probably others. The point is that some flexibility is required on this point. I agree with your comments about mandating that fast start should allow for H.245 to be started at any time. I didn't contest the wording as it seemed to me that whatever wording was in the standard, if it suited a vendor they could quite easily ignore any request to do fast start. This would total destroy any attempt to deliver some services and is hence a problem for us. I'm also interested that you state that you are looking for light-weight systems that do not use H.245. Firstly this is in conflict with the wording at the moment. Secondly, it is only an illusion of a simpler implementation, as much of H.245 is being copied into H.225 (work out how much of H.245 is included into H.225 just by referencing Capability). As to how CONNECT works in the switched network, it seems that the called endpoint sends CONNECT before the bearer path is in place. The final switch will connect the bearer when it receives CONNECT. The CONNECT is then forwarded. The point is that the CONNECT is sent before the bearer is connected through, but the bearer is connect through by the time CONNECT is received. This is difficult to emulate in our environment. You can't just delay the CONNECT in the gatekeeper until the media is established because the user is concerned with the time from 'picking up the handset' to when they can speak and are not concerned with how this relates to the timing of the CONNECT message. Some one said the switched network delay in this instance is less than 100ms. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >Sent: 18 December 1997 01:52 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Fast Start issues > >Friends, and especially Pete, > >It really does seem to me that it is possible to get everyone happy. I >would like to try and convince you (Pete) that: > a. you can get EXACTLY what you need, in the fastest, most correct >way >possible, right now, and > b. Intel's FastStart is really an important and useful thing as is >for >H.323. > >It is possible that a single sentence needs to be added to the >FastStart >text (see below in the paragraph starting "The thing that you >require..."). >But mainly I believe that there is a small misunderstanding going on, >which >is main the source of the problem. > >Pete, to get this extra "intelligence" you want, I believe that in most >cases you must use gatekeeper routed signalling. The called gatekeeper, >acting as a proxy for the called user, must send the H.245 port in the >CallProceeding message, H.245 negotiation must be used, and the CONNECT >message must come at the end, after all location/media negotiations are >over and media is available. > >I say "in most cases" because there are some cases where you will >probably >choose to do some intelligence in the LRQ phase, before the CallSetup >is >sent. In these cases it might be possible to know that the CallSetup >message is really being sent to the correct Terminal, and so you can >then >use FastStart to that Terminal. There are also other cases where you >may >choose to do FastStart with to the user's gatekeeper, have the >gatekeeper >play out a prompt saying something like "we are looking for your user >now", >have the gatekeeper do H.245 negotiation with the caller on behalf of >the >callee, and in the end establish a new media channel to the final >negotiated endpoint, breaking the original media channel negotiated >with >the gatekeeper in the FastStart. All this can be done now by using a >combination of FastStart and "classic" H.323 signalling. > >The "misunderstanding" I was alluding to earlier is this: you are >correct >that most endpoints until now unfortunately did CONNECT before media >negotiation. This is a very unfortunate breaking of Q.931 semantics >which >could have been avoided, and we should try hard to return to the normal >situation where CONNECT is sent only at the end of the entire call >establishment procedure. My problem is with the 2nd requirement you >gave in >an earlier posting: > >>we want to delay establishing media until after >>CONNECT so that the gatekeeper can do some intelligent stuff. > >I definitely DON'T want to delay establishing media until after >CONNECT. >And I claim that this is NOT needed for the gatekeeper to do some >intelligent stuff. > >The thing that you require, that is not quite there in the current >FastStart proposal, is that "even if a connection is made using >FastStart, >it shall be possible for either endpoint to start H.245 negotiation at >any >point in the conversation". I would be willing to go with this in the >spirit of compromise. (although personally I feel that such "shalls" >are >about as strong as "An H.uman endpoint shall not eat pork." Lot's of >people >who claim "Bible compliance" do not follow this shall, and somehow the >world continues to interoperate...) > >We at VocalTec, as part of our CMA work, support many of the scenarios >you >talk about, and we do it quite quickly (we think as quickly as >logically >possible in fact). Some of them require H.245, some require gatekeeper >routed signalling, some can be done with FastStart alone. > >I want to go on record saying that we DEFINITELY want to encourage >finishing the H.245 negotiation before CONNECT if it happens. This >function >is in H.323 now, and it is *the thing* that allows us to do the >scenarios >that Pete seems to want. We believe that this is how complex services >will >have to work in H.323. This allows H.245 and H.225 to go completely >independently and in parallel, and the poor CONNECT message can just be >the >final word saying "you're on the air". Logically, if you need H.245 for >your call, this is the fastest possible way to get it. > >You may be thinking, quite correctly "If Scott thinks that the next >generation of terminals is going to do H.245 before CONNECT then why in >the >world does he need FastStart?" This is a good question, but it has a >very >good answer (I'll bet you thought I would have one....) > >We perceive an absolute market requirement for the shortest, simplest, >fastest, lightweightest, stupidest kind of Internet Telephones, and >that a >system that cannot support such devices will be very vunerable to >attack >from competing systems that can. It is very important to be able to >build >"dumb telephone systems" as well as "intelligent ones". FastStart is a >great step forward for dumbness ;-). (sorry Jim). > >At the risk of repeating myself, even in the some of the scenarios Pete >mentions it is useful to use FastStart. It allows a gatekeeper to >answer >immediately (i.e. "as fast as possible") and reassure the caller that >although the system may take a few seconds to find the user and >negotiate, >this is being done. This is the way to port standard call center stuff >to >IP seamlessly. The "call center gatekeeper" answers in one round trip >with >FastStart, sends a CONNECT, and then the ACD-function starts up the >real >H.245 as part of its thing while blasting out music on hold. > >The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >CONNECT message. We believe that we in the H.323 community should do >everything possible to return the CONNECT message to its true Q.931 >meaning >of "you have end to end bearer NOW." The little fight over billing we >had >at SunRiver is only one of the issues. It is very confusing for people >and >systems to have CONNECT all of a sudden mean something else. Granted, >there >is nothing that we can do now about v1 systems, but we believe very >deeply >that every effort should be made to delay CONNECT until all >media/location >decisions are over, there is bearer, and talking/seeing can occur. This >is >what the CONNECT message is about. The fact is that it is possible to >do >H.245 upon CallSetup, and the system can take as long as it needs to do >"intelligence" before the CONNECT message. Remember that these >intelligent >things take some time, at least a few round trips, and in our >experience if >you start doing them you have plenty of time to negotiate media via >H.245. > >I hope that it is clearer now why I have a problem with any scheme to >"delay establishing media until after the CONNECT message." This is a >bad >habit that we need to end. I hope too that it is clearer why I like the >FastStart. We need good old dumb "black telephone service." If you >have >been listening to the IETF noise over this issue, you will know that >this >attack on H.323 is being taken seriously by many customers. Fast Start >answers that attack and adds a real new feature to H.323. > >Sincerely, > >Scott Petrack >

1 0

Revised H.310 version2
by Kiyoshi SAKAI 18 Dec '97

18 Dec '97

Dear SG16 colleagues, Toward the coming SG16 meeting, I have uploaded the draft revision ducument of H.310 to the "Incoming" directory of GCL's ftp site. The file name is "H310v2-4.doc" and it has been created by MS-Word97 (US version) then converted to the ver.6.0/95 compatible format. Main changes against existing version 1 are as follows: 1. Changes proposed in APC-1259(Contribution to the Sunriver meeting) - Corrections described in the H.310 Implementers Guide are imported. - An informative description in the H.310 Implementers Guide about H.310 CorrelationID is imported as AppendixIII. 2. Changes made after APC-1259 - Proposed corrections in COM 16-55 and APC-1300(Contribution to the Sunriver meeting) regarding the H.320/H.321 interoperation mode stack of RAST-5 terminals are adopted. - Proposed additions in APC-1299(Contribution to the Sunriver meeting) regarding the procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals are included. - According to the liaison from SG11/WP1(Sep.1997) , descriptions for the use of resourceId within the B-HLI in the absence of Q.2941 are totally deleted. There are still some open issues exist. Comments and contributions are solicited. If you have any problems to reproduce the document, please let me know. Best regards, K. Sakai ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Fast Start issues
by Scott Petrack 18 Dec '97

18 Dec '97

Friends, and especially Pete, It really does seem to me that it is possible to get everyone happy. I would like to try and convince you (Pete) that: a. you can get EXACTLY what you need, in the fastest, most correct way possible, right now, and b. Intel's FastStart is really an important and useful thing as is for H.323. It is possible that a single sentence needs to be added to the FastStart text (see below in the paragraph starting "The thing that you require..."). But mainly I believe that there is a small misunderstanding going on, which is main the source of the problem. Pete, to get this extra "intelligence" you want, I believe that in most cases you must use gatekeeper routed signalling. The called gatekeeper, acting as a proxy for the called user, must send the H.245 port in the CallProceeding message, H.245 negotiation must be used, and the CONNECT message must come at the end, after all location/media negotiations are over and media is available. I say "in most cases" because there are some cases where you will probably choose to do some intelligence in the LRQ phase, before the CallSetup is sent. In these cases it might be possible to know that the CallSetup message is really being sent to the correct Terminal, and so you can then use FastStart to that Terminal. There are also other cases where you may choose to do FastStart with to the user's gatekeeper, have the gatekeeper play out a prompt saying something like "we are looking for your user now", have the gatekeeper do H.245 negotiation with the caller on behalf of the callee, and in the end establish a new media channel to the final negotiated endpoint, breaking the original media channel negotiated with the gatekeeper in the FastStart. All this can be done now by using a combination of FastStart and "classic" H.323 signalling. The "misunderstanding" I was alluding to earlier is this: you are correct that most endpoints until now unfortunately did CONNECT before media negotiation. This is a very unfortunate breaking of Q.931 semantics which could have been avoided, and we should try hard to return to the normal situation where CONNECT is sent only at the end of the entire call establishment procedure. My problem is with the 2nd requirement you gave in an earlier posting: >we want to delay establishing media until after >CONNECT so that the gatekeeper can do some intelligent stuff. I definitely DON'T want to delay establishing media until after CONNECT. And I claim that this is NOT needed for the gatekeeper to do some intelligent stuff. The thing that you require, that is not quite there in the current FastStart proposal, is that "even if a connection is made using FastStart, it shall be possible for either endpoint to start H.245 negotiation at any point in the conversation". I would be willing to go with this in the spirit of compromise. (although personally I feel that such "shalls" are about as strong as "An H.uman endpoint shall not eat pork." Lot's of people who claim "Bible compliance" do not follow this shall, and somehow the world continues to interoperate...) We at VocalTec, as part of our CMA work, support many of the scenarios you talk about, and we do it quite quickly (we think as quickly as logically possible in fact). Some of them require H.245, some require gatekeeper routed signalling, some can be done with FastStart alone. I want to go on record saying that we DEFINITELY want to encourage finishing the H.245 negotiation before CONNECT if it happens. This function is in H.323 now, and it is *the thing* that allows us to do the scenarios that Pete seems to want. We believe that this is how complex services will have to work in H.323. This allows H.245 and H.225 to go completely independently and in parallel, and the poor CONNECT message can just be the final word saying "you're on the air". Logically, if you need H.245 for your call, this is the fastest possible way to get it. You may be thinking, quite correctly "If Scott thinks that the next generation of terminals is going to do H.245 before CONNECT then why in the world does he need FastStart?" This is a good question, but it has a very good answer (I'll bet you thought I would have one....) We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, and that a system that cannot support such devices will be very vunerable to attack from competing systems that can. It is very important to be able to build "dumb telephone systems" as well as "intelligent ones". FastStart is a great step forward for dumbness ;-). (sorry Jim). At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold. The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245. I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323. Sincerely, Scott Petrack

1 0

FW: Submission of Internet draft
by Pete Cordell 17 Dec '97

17 Dec '97

Dear All, I have finally got around to submitting the URL stuff as an Internet-draft. This contains no changes to what was previously put in. When it gets accepted I will forward it to the URL-REG list to see if they have any comments. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Pete Cordell >Sent: 17 December 1997 19:00 >To: 'internet-drafts(a)ietf.org' >Subject: Submission of internet draft > >Please may I submit the following Internet draft. I have called it: > >draft-sg16-conv-url-00.txt > >Please let me know if there is a problem with this name. > >Many thanks, > >Pete Cordell > >============== >INTERNET-DRAFT Cordell >draft-sg16-conv-url-00.txt BT > Editor > Dec 16, 1997 > Expires: 21 June 1998 > > Conversational Multimedia URLs > >Status of this memo > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its > areas, and its working groups. Note that other groups may also > distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- > Drafts as reference material or to cite them other than as > ``work in progress.'' > > To learn the current status of any Internet-Draft, please check > the ``1id-abstracts.txt'' listing contained in the Internet- > Drafts Shadow Directories on ftp.is.co.za (Africa), > nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), > ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). > >{Editor's comments are in braces} > >Abstract > >The evolving technologies for real-time conversation over the Internet >require URLs to provide user contact information. As there are many >protocols (including some that are not Internet based) that can be used > >for inter-user conversation, this document describes a two stage >transaction process for obtaining a URL that can be used to initiate >conversation. The first stage involves retrieving a list of protocol >specific URLs in a MIME encoded file. The MIME type enables an >appropriate application to be launched which will analyse the presented > >URLs and select the most appropriate one. The second stage involves >interpreting the protocol specific URL and initiating the conversation. >The protocol specific URLs are encoded in a URL form so that they can >be >embedded directly into HTML pages. This allows the first stage to be >omitted. The document describes the format of the MIME encoded list of > >URLs, and the format of a number of protocol specific URLs. > > >Contents > >ABSTRACT 1 >CONTENTS 1 >REVISIONS SINCE LAST VERSION 1 >1. INTRODUCTION 1 >2. THE MIME FILE 2 >3. PROTOCOL SPECIFIC URLS 3 >3.1. COMMON URL ELEMENTS 3 >3.2. H.323 URL 3 >3.3. H.324 URL 5 >3.4. H.320 URL 5 >3.5. POTS URL 5 >3.6. T.120 URL 5 >4. E-MAIL LIST 6 >5. SECURITY CONSIDERATIONS 6 >6. ACKNOWLEDGEMENTS 6 >7. REFERENCES 6 >APPENDIX 1 - COMPLETE ABNF 6 >AUTHOR'S ADDRESS 7 > > >Revisions Since Last Version > >* Removed call-id as a parameter > > >1. Introduction > >Internet technology allows for real-time conversation to take place. >It >also provides a convenient method of obtaining user location >information >in the form of URLs. (Note: As used here, the term user can refer to >a >person, a machine, or any other entity a person or machine may care to >have a conversation with.) These can describe Internet conversational >protocols, and non-Internet based conversational mechanisms such as >POTS. As there are a number of conversational protocols that can be >used to contact a user, this document describes a two stage process for > >initiating conversation, with the first stage being optional. The >first >stage retrieves a list of protocol specific URLs in a MIME encoded >file. >This list is analysed and the most appropriate URL is selected. The >second stage involves interpreting the protocol specific URL. The >protocol specific URLs are in a form that can be directly embedded into > >HTML pages so that the first stage can be omitted. > >The scheme presented here is designed to leverage as much as possible >of >existing infrastructure. As other technologies become common place >(such as CMA [1] and vCard [2]) the mechanisms presented here may >lapse. > >The remainder of this document describes the format of the MIME file, >and the format of a number of protocol specific URLs. > > >2. The MIME file > >The first stage in the contact process is to obtain a list of possible >contact mechanisms. To enable a single link to be placed in an HTML >page, an indirection method is used wherein a link to a MIME encoded >file is made. The MIME type of the file is: > > APPLICATION/TALKTO > >and the default extension is: > > .tlk > >The MIME file should be retrieved using HTTP. Files that contain time >dependent protocol specific URLs should ensure that the files are >marked >as non-cacheable. > >The MIME encoded file consists of ASCII text and lists a number of >protocol specific URLs that can be used to contact a remote user. The >section below describes a number of protocol specific URLs, but this >should not be considered an exhaustive list. > >Each protocol specific URL is presented on a separate line with no >leading white space. The preferred line break convention is the one >used for HTTP (CRLF), but applications must be tolerant to other line >break conventions so that files can be readily edited on diverse hosts. > >Each protocol specific URL may be followed by some white space and a >comment. The comment should be in a form that can be presented to a >user as part of a manual selection process. By default the comments >are >ignored. For example: > ><protocol_specific_url> ;My home number ><protocol_specific_url> ;My bosses number > >Lines which begin with white-space should be considered as comments and > >ignored. >The order of the URLs should be such that the most preferred URL is >presented first, and the least preferred is presented last. When >interpreting the file, if a URL is unsupported, or is not understood, >it >should be skipped. Endpoints are encouraged to take into account the >preference order indicated by the file when selecting a URL, but this >is >not required. Parsing of the file may continue if a contact attempt >fails. > >Note that the file does not contain any other information such as the >times when specific URLs are valid. This enables a simple file format >that does not have to cope with arbitrary search sequences and the >complications of time-zones. Therefore, strictly, the file is only >valid at the time it is downloaded and the HTTP cache control >attributes >should be used to control its validity as required. > >As with any file downloaded by HTTP, it can be a static file on a >server >or dynamically generated by an executable. The data for the latter may > >be uploaded by schemes such as the VoIP's CMA protocol[1]. > >Validation of who is allowed to obtain various types of location >information can be done using WWW-Authentication and cookies. This >document provides no additions to these HTTP mechanisms. > >Example URLs for downloading the MIME file are: > > http://talkto.mycom.com/me.tlk > http://talkto.mycom.com/cma.exe?me > >{For consideration: >The above scheme is simple, but not extensible. It may be prudent to >define a basic extension scheme to cope with any future problems. The >follwing scheme is suggested for consideration. >If the line starts with a "+", then this line contains a parameter that > >is optional to interpret, i.e. parsing of the file can continue even if > >the parameter is not understood. >If the line starts with "*", then the line contains a parameter that >must be understood. The rest of the file should only be interpreted if > >the parameter is understood, but earlier lines can be interpreted even >if the paramter is not understood. This definition allows simple >parser >features and complex parser features to co-exist in the same file. >e.g. >a file might contain: > >h323:pete@h323.bt.com >*time=17:00-8:30 >h323:home@h323.bt.com > >where time is a paramter to be defined in the future. Parsers that >don't understand the time parameter could use the first URL, but not >the >second}. > > >3. Protocol Specific URLs > >Protocol specific URLs describe contact information for a specific >protocol. This section describes a number of these URLs, but this >should not be considered an exhaustive list. Other suitable URLs >include the IETF's SIP, VoIP's CMA, and Microsoft's CALLTO schemes. >Although the main intention of these URLs is to describe conversational > >protocols, URLs such as CHAT and MAILTO may be appropriate as a last >resort. Under certain circumstances RTSP URLs may also be useful. >This section starts with a description of some common elements. These >are then used in the protocol specific URLs. > > >3.1. Common URL elements > >This sub-section describes common elements from which the protocol >specific URLs are constructed. A number of the elements use >definitions >from [3]. > > network = packet-network | switched-network > packet-network = "ip" | "tls" | "udp" | "aal5" > ; ip = IP connection without TLS > ; tls = IP connection made over TLS > ; udp = IP connection made over UDP - > ; this channel may be made reliable > ; using additional means > ; aal5 = ATM AAL5 call > switched-network = "pots" | "isdn" | "aal1" > ; pots = GSTN or ISDN speech/audio call > ; isdn = ISDN data call > ; aal1 = ATM AAL1 call > address = ip-address | phone-address > > ip-address = hostport ; hostport defined in [3] > > phone-address = global-phone-number *[ "&" global-phone-number ] > ; global-phone-number defined in [4]. > ; H.323 endpoints do not support the > ; wait for tone pause character > > param-list = param | param param-list > param = ";" h323-param > >Telephone numbers in phone-address should always be presented in a full > >international form, including the "+" sign. It is the responsibility >of >endpoints and/or gatekeepers to convert these to location specific >numbers. > > >3.2. H.323 URL > >{Note: the format of this URL has been structured to have a basic form >of h323:pete@h323.bt.com. This is because users are familiar with this > >format, and it is intuitive what it means. However, this does present >problems when e-mail ids which include an @ are included in the URL. >One solution is to include the e-mail @ in its escaped form, i.e. %40. > >Another option is to specify that parsers should be tolerant of >duplicate @ signs. Yet another option is to use an alternative >character to represent the @ in the basic URL form, i.e. >h323:pete/bt.com. This appears less intuitive, and there may be many >erroneous URLs generated as the number of /s at the beginning become >very significant, such as in h323:/pete.bt.com which should resolve to >an IP address only. } > >There are two H.323 related URLs. The first form initiates a call >directly based on the information in the URL. The second initiates a >call based on information that is obtained by first issuing an H.323 >LRQ. > >For the first form, the scheme is: > > h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address > [h323-param-list] > >and the second form is: > > lrqurl = "lrq" "://" ip-address [h323-param-list] > >where: > > h323-address = user-part | address | user-part address > user-part = user [ ":" type ] "@" > user = 1*alphanum ; alphanum defined in [3] > type = "e164" | "h323id" | "email" > >The 'network' part of the URL need only be present if the network is >not >of type IP (i.e. ip is the default network). > >If an ip-address is used in the 'address' field, the 'user' and 'type' >fields specify the information to be placed in the destinationInfo part > >of ARQ and destinationAddress part of SETUP. The 'type' field >specifies >the type of AliasAddress. If the user field starts with a digit, "*" >or >"#" the default type is "e164", otherwise it is "h323id". > >If a 'phone-number' is used in the address field any 'user' and 'type' >parts are placed in the remoteExtensionAddress part of SETUP, and the >phone number is placed in the destinationInfo part of ARQ and >destinationAddress part of SETUP. It is the responsibility of the >receiving H.323 over ISDN gateway to transfer the >remoteExtensionAddress >to the destinationInfo part of ARQ and destinationAddress part of SETUP > >prior to making the onward call. > >To place an aliasAddress containing an @ sign in the 'user' field, the >escaped form of the @ sign must be used, i.e. %40. > >If the 'address' field is of type ip-address this is placed in the >destCallSignalAddress fields of both ARQ and SETUP. > >The H.323 URL may have a number of parameters associated with it. If >an >endpoint does not know how to handle a parameter then it shall ignore >the entire URL. At the time of writing the valid parameters are: > > h323-param = cid-param | token-param | l2-param > cid-param = "cid" "=" UUID ; UUID is specified in [5] > token-param = "token" "=" "0x" 1* hex > l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) > ; Layer 2 format > >The cid parameter encodes a UUID that should be placed in the >conference >ID field of the ARQ and SETUP messages. This field may appear a >maximum >of 1 time in the URL. > >If a conference Identifier is specified, then the conferenceGoal should > >be "join" in the outgoing SETUP message, otherwise it should be >"create". > >The token field represents a hexadecimal representation of an octet >sequnce. 0, 1 or more token parameters may be included in a URL. > >The 'l2' parameter allows for different packetisation schemes to be >used >over switched network connections. If applicable, the default is PPP. > >Note that an H.323 URL with a network type of ISDN indicates that H.323 > >is carried over the ISDN using a layer 2 protocol such as PPP >(specified >by the 'l2' parameter). It does not mean that the H.323 system should >locate an H.320 gateway and use this to communicate over the ISDN. The > >H.320 URL should be used to indicate this. > >Example H.323 URLs are as follows: > >h323:pete@h323.bt.com > AliasAddress = pete, AliasAddress type = h323id, > destCallSignalAddress = h323.bt.com. > >h323://pete@h323.bt.com > Same as above > >h323:646436@h323.bt.com > AliasAddress = 646436, AliasAddress type = e164, > destCallSignalAddress = h323.bt.com. > >h323:pete@ -- This form requires a gatekeeper to determine a > destCallSignalAddress > AliasAddress = pete, AliasAddress type = h323id, > destCallSignalAddress = GK supplied. > >h323:pete.bt.com > destCallSignalAddress = pete.bt.com > > >h323:/tls/pete%40bt.com:email@bt.com;token=0x5435;token=0xcdfe;cid=f81d4 >fbf-7dec-11d0-a765-00a0c91e6bf6 > This call should be setup over a secure TLS channel. > AliasAddress = pete(a)bt.com, AliasAddress type = email-ID, > destCallSignalAddress = bt.com, Two tokens are supplied. > A conference ID is also specified. > >h323:/pots/+1-515-234-5645 > H.323 over PPP over GSTN. destCallSignalAddress = an address of an > H.323 over POTS gateway. This may be gatekeeper provided. > +1-515-234-5645 is placed in destinationInfo part of ARQ and > destinationAddress part of SETUP. > >lrq:pete@h323.bt.com > Causes an LRQ to be performed first. > > >3.3. H.324 URL > >The format of the H.324 URL is: > >h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address > >The default switched-network type is "pots". H.324i is denoted by >having a switch-network type of "isdn". >An example URL is: > > h324:+1-515-234-5678 > >or: > > h324:/isdn/+1-515-234-5679&+1-515-234-5680 > > >3.4. H.320 URL > >The format of the H.320 URL is: > > h320url = "h320" ":" phone-address > >The network type is always "isdn". An example is: > > h320:/isdn/+1-515-234-5679&+1-515-234-5680 > > >3.5. POTS URL > >The telephone number scheme for a basic voice call is defined in [4]. > > >3.6. T.120 URL > >The format of the T.120 URL is: > > t120url = "t120" ":" [ "/" [ network ] "/" ] address [t120-param-list] > >The following parameters are valid: ??????? > > >4. E-mail list > >As many groups are interested in conversational URLs including SG16, >VoIP, MMUSIC, PINT, TIPHON, URL-REG etc), a separate e-mail list has >been set up. You can subscribe to the list by including the word >"subscribe" in the message body text of an e-mail sent to the address: > > h323-url-request(a)vocaltec.com > >E-mail can be sent to the list at the following address: > > h323-url(a)vocaltec.com > > >5. Security Considerations > >Umm... > > >6. Acknowledgements > >7. References > >[1] "Service Interoperability Implementation Agreement," IMTC VoIP >Forum >[2] vCard >[3] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource > Locators (URL)," RFC1738, December 1994. {Editor's note: A new > version of RFC1738 is being produced so this reference will have > to be changed.} >[4] A. Vaha-Sipila, "URLs for Telephony," > draft-antti-telephony-url-03.txt, 21 Nov 1997 >[5] "Call Signalling Protocols and media Stream Packetization for > Packet Based Multimedia Communications Systems," > ITU-T Recommendation H.225 Version 2, January 1998 > > >Appendix 1 - Complete ABNF > >all-urls = h323url | lrqurl | h324url | h320url | t120url > >h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address [ >h323-param-list ] >lrqurl = "lrq" "://" ip-address [ h323-param-list ] >h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address >h320url = "h320" ":" phone-address >t120url = "t120" ":" [ "/" [ network ] "/" ] address [ t120-param-list >] > >network = packet-network | switched-network >packet-network = "ip" | "tls" | "udp" | "aal5" >switched-network = "pots" | "isdn" | "aal1" > >h323-address = user-part | address | user-part address >user-part = user [ ":" type ] "@" >user = 1*alphanum ; alphanum defined in [3] >type = "e164" | "h323id" | "email" > >address = ip-address | phone-address > >ip-address = hostport ; hostport defined in [3] > >phone-address = global-phone-number *[ "&" global-phone-number ] > ; global-phone-number defined in [4]. > ; H.323 endpoints do not support the > ; wait for tone pause character > >h323-param-list = ";" h323-param | ";" h323-param h323-param-list > >h323-param = cid-param | token-param | l2-param >cid-param = "cid" "=" UUID ; UUID is specified in [5] >token-param = "token" "=" "0x" 1* hex >l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) > ; Layer 2 format > >t120-param-list = ";" t120-param | ";" t120-param t120-param-list >t120-param = {???????} > > >Author's Address > >Pete Cordell >BT Labs >MLB 4/15 >Martlesham Heath >Ipswich >IP5 3RE >UK >e-mail: pete.cordell(a)bt-sys.bt.co.uk > > >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > >

1 0

Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Toby Nixon 16 Dec '97

16 Dec '97

At the IMTC VOIP Forum meeting last Friday, Jeff Pulver announced that he has planned next fall's VON conference for the week of September 14-18 in Washington DC. Apparently, he didn't know that there is a Study Group 16 meeting planned for the same time slot. He's really in a bind, though, because of conflicts with other conferences and trade shows, holidays, etc., and is very concerned that key SG16 participants won't be able to attend VON with the current schedule. What is the SG16 WP2 workload likely to be at that fall '98 meeting? Is it conceivable that we could schedule WP1 and WP3 meetings mostly in the first week, and meetings of WP2 and its questions mostly in the second week, so as to allow for participating in VON? -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

2 1

Re: Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Toby Nixon 16 Dec '97

16 Dec '97

Istvan Sebestyen [SMTP:istvan.sebestyen@mch.pn.siemens.de] wrote: > In my personal opinion WP2 will - as always be - very busy, and > occupied with much work. In addition you have to deduct the opening > and closing Plenaries of the WPs and of SG16 (the later one about > 1,5-2 days). So, in practice the question is if you can queeze WP2 > work in 2,5-3 days (Monday-Wednesday 2nd week), > without giving time for preparation of reports, > documents, last minutes edits etc. for the closing plenaries. > > In my opinion this will be very difficult. and Gary Thom [gthom(a)DELTA-INFO.COM] wrote: > I expect that at the Sept 98 SG16 meeting, we will have several > documents to Determine. These may be: H.MediaMIB, > H.246 Annexes for H.324/H.320 and H.324/H.323, H.235V2, > H.245V4, T.130/H.AVC. Maybe also H.323V3, H.225.0V3. Well, I was afraid of that when I was speaking with Jeff on Friday. I'll let him know, and he'll have to decide whether to try to reschedule VON or do it without key SG16 participants. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Istvan Sebestyen 16 Dec '97

16 Dec '97

At 14:58 15.12.1997 -0800, Toby Nixon wrote: >At the IMTC VOIP Forum meeting last Friday, Jeff Pulver announced that he >has planned next fall's VON conference for the week of September 14-18 in >Washington DC. Apparently, he didn't know that there is a Study Group 16 >meeting planned for the same time slot. He's really in a bind, though, >because of conflicts with other conferences and trade shows, holidays, etc., >and is very concerned that key SG16 participants won't be able to attend VON >with the current schedule. > >What is the SG16 WP2 workload likely to be at that fall '98 meeting? Is it >conceivable that we could schedule WP1 and WP3 meetings mostly in the first >week, and meetings of WP2 and its questions mostly in the second week, so as >to allow for participating in VON? > > -- Toby >___________________________________________________________ >Toby Nixon, Program Manager - NetMeeting >http://www.microsoft.com/netmeeting >Microsoft Corporation, Applications and Internet Client Group, Redmond WA >USA >+1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com > > Toby, to your question... In my personal opinion WP2 will - as always be - very busy, and occupied with much work. In addition you have to deduct the opening ang closing Plenaries of the WPs and of SG16 (the later one about 1,5-2 days). So, in practice the question is if you can queeze WP2 work in 2,5-3 days (Monday-Wednesday 2nd week), without giving time for preparation of reports, documents, last minutes edits etc. for the closing plenaries. In my opinion this will be very difficult. Regards, Istvan ------------------------------------------------------------------ Istvan Sebestyen Siemens AG PN GS 94 Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me can get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

1 0

Re: Pete Cordell's FastStart issues
by Neil Starkey 11 Dec '97

11 Dec '97

Please do put this on the list. This is an issue we (DataBeam) are interested in but have lost out on part of the discussion. Neil At 12:23 PM 12/8/97 -0800, Toby Nixon wrote: >Might I suggest that this discussion be broadened to include the ITU-SG16 >reflector instead of sending a long list of recipients each time? > >> -----Original Message----- >> From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk] >> Sent: Monday, December 08, 1997 9:16 AM >> To: 'pete.cordell(a)bt-sys.bt.co.uk'; 'Narjala_Bhasker(a)ccm.jf.intel.com'; >> 'Vineet_Kumar(a)ccm.jf.intel.com'; 'amir(a)radvision.rad.co.il'; >> 'gthom(a)DELTA-INFO.COM'; 'lindbergh(a)pictel.com'; 'reid(a)pictel.com'; >> 'Scott_Petrack(a)VOCALTEC.COM'; 'okubo(a)gctech.co.jp'; Toby Nixon; Steve >> Liffick; 'karl.klaghofer(a)MCH.PN.SIEMENS.DE'; 'amotz(a)radvision.rad.co.il'; >> 'sebes(a)PNSTA1.ZFE.SIEMENS.DE'; 'dskran(a)ascend.com'; >> 'nstarkey(a)databeam.com'; 'Robert.Callaghan(a)SIEMENSCOM.COM'; >> 'gkajos(a)videoserver.com'; 'ggf(a)lucent.com'; 'jeff(a)pictel.com'; >> 'john.boucher(a)bt-sys.bt.co.uk'; 'gkisor(a)ideal.jf.intel.com'; >> 'reinhard.scholl(a)oen.siemens.de'; 'ofer(a)radvision.rad.co.il'; >> 'nilsson_m_e(a)bt-web.bt.co.uk'; 'helmut.schink(a)oen.siemens.de'; >> 'roni_e(a)accord.co.il'; 'gfargo(a)intecom.com'; 'adfranklin(a)lucent.com'; 'Jim >> Toga' >> Subject: RE: Pete Cordell's FastStart issues >> >> Jim et al., >> >> I'm glad we've got a discussion going on this. This seems to be a >> really big issue that can have a major impact on the future of H.323. I >> know we're all really busy, but come January we will be stuck with what >> ever we decide, so I'm hoping that other people can jump in here to >> thrash out the issues as much as possible. The more input, the better >> the solution is likely to be. >> >> I've put comments in below. From the comments presented though I don't >> think we are on the same wavelength yet, so most of the comments are >> related to the problem space rather than any solutions. >> >> Pete >> ================================= >> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================= >> >> >> >---------- >> >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] >> >Sent: 07 December 1997 19:18 >> >To: pete.cordell(a)bt-sys.bt.co.uk; Narjala_Bhasker(a)ccm.jf.intel.com; >> >Vineet_Kumar(a)ccm.jf.intel.com; amir(a)radvision.rad.co.il; >> >gthom(a)DELTA-INFO.COM; lindbergh(a)pictel.com; reid(a)pictel.com; >> >Scott_Petrack(a)VOCALTEC.COM; okubo(a)gctech.co.jp; tnixon(a)MICROSOFT.COM; >> >stevel(a)MICROSOFT.COM; karl.klaghofer(a)MCH.PN.SIEMENS.DE; >> >amotz(a)radvision.rad.co.il; sebes(a)PNSTA1.ZFE.SIEMENS.DE; >> >dskran(a)ascend.com; nstarkey(a)databeam.com; >> >Robert.Callaghan(a)SIEMENSCOM.COM; gkajos(a)videoserver.com; >> >ggf(a)lucent.com; jeff(a)pictel.com; john.boucher(a)bt-sys.bt.co.uk; >> >gkisor(a)ideal.jf.intel.com; reinhard.scholl(a)oen.siemens.de; >> >ofer(a)radvision.rad.co.il; nilsson_m_e(a)bt-web.bt.co.uk; >> >helmut.schink(a)oen.siemens.de; roni_e(a)accord.co.il; gfargo(a)intecom.com; >> >adfranklin(a)lucent.com >> >Cc: jtoga(a)ideal.jf.intel.com >> >Subject: Re:Pete Cordell's FastStart issues >> > >> >Pete, (and others) >> > >> >Let me try and respond to your issues and hopefully we can resolve this >> >in >> >a relatively concise manner. Before we get started though I would like >> >to >> >make a couple of points clear: >> > >> >Recall that the "fast start" problem as stated previous to the Israel >> >meeting and formalized in the contribution to that meeting, was the >> >following. To provide a minimal round trip time connection sequence, >> >for >> >simple constrained calling scenarios. The requirement was to have >> >minmal >> >engineering impact to current shipping products and complete backward >> >compatability. >> I've looked through my notes and I can see any authoritative, exclusive >> list of what the fast start should be expected to solve. I don't see >> anything that said it should be restricted to "simple constrained >> calling scenarios". >> > >> >I have always been a proponent of Gatekeepers and the functionality, >> >features, and services that they can provide. >> > >> >Everyone (including you), supported the final version of FastStart >> >which >> >came out SunRiver with the additions of bi-directional capabilities. >> >With >> >the presentation of your alternative approach there was never any clear >> >motivation for developing the more complicated version other than you >> >'didn't like' the current form. I'm happy to see you've presented a >> >real >> >issue to which you would like a solution. >> > >> >I would like codify my understanding of your issues and see if we can >> >find >> >a solution to them. I _think _you imply the need for a low overhead >> >'mode >> >switch' which really has nothing to do with FastStart, but let me see >> >if I >> >understand your points. >> To me connection setup (i.e. user-to-user connection) is pretty much all >> that H.323 is about. Once a connection is setup there is little more >> for H.323 to do, other than tear-down. >> > >> > >> >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote: >> >[SNIP] >> >> Each user has an account on the system. They can use >> >>it as a single number by which to contact them by. As you move from >> >office to home to mobile, >> >>you configure it using a web browser with >> >>the number to contact you on. People trying to contact you dial a >> >>single number and the platform forwards the call to the correct >> location. >> >> It also allows people to leave voice messages on the system. >> >>Additionally you can configure it to do things like try the office phone >> >>first, then the mobile and if that doesn't work leave a message. This >> >>sort >> >> of flexibility is not easily addressed by a directory. It >> >>can also receive e-mails and faxes etc. >> >> >> >[SNIP] >> > >> >>This is admittedly not rocket science, and you've probably come across >> >>services like this already. Our job is to move this to the IP world. >> > >> >Why can't you can accomplish this today (in R2) with the multiple alias >> >registrations (that fact that you may use WEB front end is irrelevent)? >> >The >> >Gatekeeper then has his 'rotary switch' of locations to look through to >> >find the current active location. This is much like (if not exactly) >> >VocalTec's CMA architecture. >> Your right, the configuration side of things is not the issue. >> > >> >>Product Impact >> >>============== >> >>To understand the impact of this on the protocol, let's look at the case >> >>of using a search algorithm to look for a user and also returning a call >> >>after interrogating the voice bank. >> >> >> > >> >Tying user-network signalling to network-network signalling in the >> >protocol >> >is bad practice, limiting and cumbersome. >> I agree, network-network signalling is for another day. However this >> issue is very much in the user-network signalling area. The issues >> remain even if only one gatekeeper is involved (which hopefully implies >> that there is no network-network signalling). >> > >> >>Let's assume the system is configured to contact my work number first >> >>and them my mobile number. In this case the final connected endpoint is >> >> >> not known until the CONNECT message is received. Hence the >> >>capabilities of the endpoint you will be talking to are not known for >> >>sure until you get CONNECT. >> > >> >I see this, and agree it is entirely true. It has no effect however on >> >the >> >the capabilities of the _calling_ party. They _are_ known, and there >> >is no >> >reason why the possibile capabilities should change. >> Correct >> > >> >>This is not a problem with the basic call setup sequence as the H.245 is >> >> >>not established until after CONNECT. >> > >> >This is not quite true. There has been the ability (since 3/96) to >> >start >> >H.245 at any point after the SETUP message is received. This required >> >two >> >things, which by the way would be required in all of these scenarios. >> > >> >The caller and callee has to be able to deal with H.245 and possibly >> >media, >> >'early'. >> >The caller has to place the H.245 port in the Setup message. >> >(Alternatively the callee can place the H.245 port in the Call >> >Proceeding/Alerting message) >> True, but hopefully you'll agree with me that in this case the >> gatekeeper could delete any H.245 addresses from messages other than >> CONNECT and it would get the desired behaviour. This seems to be a >> pretty NULL operation as nobody seems to be sending H.245 addresses in >> messages other than connect anyway. >> > >> >>However, with fast connect we want to start capability negotiation as >> >>soon as possible, and are not able to wait until CONNECT. >> > >> >The Determined version of FastStart DOES do a full capability exchange >> >before the CONNECT. (althought it does not provide for an iterative >> >_negototiation_, as this defeats the Fast portion of FastStart). >> I have problems with saying the FastStart shall be 1 round trip or bust. >> The intent seems to have been that a minimum of round trips should be >> used compatible with negotiation, security etc. If a particular case >> requires an extra round trip, then that is the minimum number of round >> trips that case can be set up in. That doesn't break fastStart. I >> would say it's good because it has meant that we don't fall back to the >> 6 1/2 round trips that we typically need. >> > >> >>This also has the benefits that we can listen to announcements prior to >> >the CONNECT >message (such as "The >> > >number you have dialled has > changed, but we are re-routing you >> >anyway"). >> > >> >This is EXACTLY what FastStart provides as soon as the Setup is >> >recieved, >> >the recipient may start playing media back to the caller. The caller >> >may >> >be constrained from sending media to the callee until the Connect is >> >received - just as it works in the circuit world. >> I was trying to capture the issues here, not saying that the current >> fast start doesn't meet any of them. Basically we have conflicting >> requirements here 1) we want to establish media prior to CONNECT to >> allow announcements, 2) we want to delay establishing media until after >> CONNECT so that the gatekeeper can do some intelligent stuff. This is >> what makes this topic so interesting!!!! >> > >> >>However, if the system gives up ringing my work number and then tries >> >>the mobile number, it has to present a new set of capabilities to the >> >calling endpoint. >> > >> >That is true, and this can occur by simply sending another Call >> >Proceeding >> >message (or Alerting) with the new caps. There is no need however for >> >the >> >_caller_ change or otherwise resend its caps..... In other words the >> >Gatekeeper will still be presenting the same set to the subsequent >> >callees >> >as it polls them. >> You're right that the caller does not have to generate new caps. >> However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint >> breaks H.225, and so would not be backwards compatible. >> > >> > >> >>Now I'm in the mode of interrogating the voice messages that have been >> >>left for me. My endpoint is connected to the sub-system that plays out >> >the recorded >> >>messages and it asks me if I want to return the >> >>call. To do this the system needs to create an outgoing call, and >> >>locally generate a ringing tone. When the remote party answers the two >> >endpoints need >> >>to be connected together. >> > >> >This is either some form of a transfer (from a protocol point of view) >> >or >> >shouldn't it be hidden from the endpoint in terms of signalling? >> In a distributed world there is only so much that you can hide from an >> endpoint. That's why this topic is so important. To roll out customer >> friendly services the endpoints need to support some basic capabilities. >> Hopefully this is worth endpoint vendors doing as useful services mean >> that people can use there endpoints for more things. Thus the >> technology is more likely to catch on, than if you are only likely to >> get reasonable service from a call centre via good old POTS. >> > >> >>You may say that the FACILITY message could be used to do this. >> However, >> >the caller has state stored >> >>in the platform/gatekeeper (such as where they are in the menus etc.) so >> >that when they finish this new >> >>call they can go back to interrogating their messages. This would not >> be >> >possible with the >> >>FACILITY approach. >> > >> >It would seem that exposing this bookkeeping/signalling would require a >> >_large_ commitment on the part of all the endpoint manufacturers - >> >wouldn't >> >it be better to provide this in an 'invisible' way? Aside from the >> >complexity/compatibiliy issues it provides for product differentiation. >> I think you're agreeing with me that the FACILITY way is a bad way to >> go. >> > >> >> >> >>WOW that's complicated!!! >> >>========================= >> >>At first sight this appears horrendous, but in actual fact it is quite >> >>simple. All it requires is for the platform/gatekeeper to be able to >> >break connections and re-establish >> >>new connections when it wants to. >> > >> >AAHHH.... so this is what you wanted! This _does_ seem like a >> >'transfer' >> >type of thing, in any case it would appear to be independant of >> >FastStart. >> A setup is almost invariably part of transfer, so I don't see that you >> can call them independent. Anyway, the report from Hertzliya says >> support for supplementary services should be included in fast setup. >> > >> >I have to admit, I'm not sure what you mean by 'connection' though. Is >> >this simply logical media channels, or is it a larger concept? >> I'm really mean establishing some sort of media exchange between users >> such as audio or video. >> > >> >[SNIP] >> > >> >> >> >>So where's the problem >> >>====================== >> >>The problem is that I can not make use of the fast setup scheme with >> >>these services, because it does not support the break and make >> capability. >> > >> >This is _new_ functionality that was never listed as a requirement of >> >FastStart, and I would argue that 'breaking and making connections' >> >goes >> >against the scope of the FastStart usefulness. >> This is where I totally disagree. The list of fast start requirements >> was never exclusive. We announced our requirements for fast start and >> no body objected to them, and some even backed them up. If you had >> objections you should have raised them at the time. >> > >> >>To do these services I need tofall back to H.245. If the >> >>standard setup is not good enough for a basic point-to-point call then >> >>it is not good enough for entities that introduce intelligence which in >> >fact have more stringent timing >> >>requirements because the breaks and makes are more difficult to conceal >> >under things like ringing. >> > >> >The 'standard setup' is no way "not good enough" for basic >> >point-to-point >> >operation. It simply as case that in certain well defined (resources >> >and >> >entities known) that optimizations can and should be made to operate in >> >simple low delay environments. >> > >> >>Assuming that the reason for implementing the gatekeeper routed model is >> >to add these sorts of features, then >> >>really the gatekeeper routed model becomes a second class citizen. This >> >is a problem for us. >> > >> >The Gatekeeper should most definitely NOT be constrained from adding >> >features and providing expanded services. The Gatekeeper routed model >> >was >> >specifically developed to hide this complexities from the endpoints, in >> >fact the endpoint cannot even tell which mode it is running in other >> >than a >> >bit in the ACF. >> > >> >The Gatekeeper is no more or less a "second class citizen" with >> >FastStart >> >as with the 'standard' signaling. In fact I believe that it has even >> >more >> >control, because it may provide an asymmetrical connection on either >> >side >> >of itself >> >forcing either the caller or callee into a particular mode of >> >operation. >> If the standard startup is good enough then we seem to be taking >> elaborate measures to tune the efficiency of the "standard setup". >> Either the standard setup is good enough or it isn't. If it is good >> enough then we don't need fast start. I happen to think that it is not >> good enough. Hence we need a solution that is good enough for the basic >> call model and is also good enough for those of us that want to add >> value. If we don't achieve this, then as far as I can see the >> gatekeeper routed model can only become a second class citizen. >> > >> >> >> >>Where to go next >> >>================ >> >>To do what I need to do, I need a fast method for making and breaking >> >>connections without first establishing the TCP connection, negotiating >> >caps, MSD, OLC, OLC ACK, >> >>and then sending media. We could achieve this by adding a break command >> >to the FACILITY message and >then having the ability to send new >> >fastCaps >> >at any time to make a new connection. This seems a minimal >> >>change from where we are at the moment and such a change would be fine >> by >> >me. >> > >> >Again I'm not clear on what you mean by 'connections', but assuming >> >that >> >you mean something like an audio channel (say 711-->723.1) than I think >> >there are a number of fine options we can pursue. (for example H.245 >> >has >> >established a 're-open' command.) >> > >> >> >> >>However, I know that Glen is interested in always running an MC, so he >> >>would want to add extra features. Others will probably also want >> features >> >that have been carefully crafted >> >>into H.245. As a result we are likely to get feature creep so that more >> >and more H.245 functionality is >> >>put into H.225. >> > >> >I completely agree that it would be a very bad thing to re-invent H.245 >> >within H.225.0. >> > >> >> I also have concerns about having two ways and two APIs (fast and slow) >> >for doing >> >>things. This explains my attempt to re-use as much of H.245 as >> possible. >> > >> >To pick a nit, we're not talking about API's; there is one way within >> >the >> >protocol to establish an H.245 connection. If you need these features, >> >flexibility and control; this is what you should do. That being said >> >there >> >are two forms of Setup/Connect messages for those >> >Endpoints/Gatekeepers/MCUs that would like to utilize them. >> To pick more nits ( :-) ), we at some point have to build what we >> propose. Therefore, we can not conceive of protocols in isolation of >> how we will build them. If one protocol idea is easier to develop than >> another then we should go with that one. So although the ITU is not >> bothered with APIs, we as contributors, should be. >> >> Most stacks that I am aware of separate out the Q.931 part and the H.245 >> part. At the moment the H.245 part knows about caps and the Q.931 part >> does not. To put caps in Q.931 we need to put an API on the Q.931 part >> that accepts caps. Therefore we really do have two APIs, which is an >> issue. >> > >> >> >> >>But let me reassure you I have no requirement to use H.245! I have a >> >>requirement to solve the problem presented above. >> > >> >The problem is to 'break and make' connections with minimal >> >overhead?..... >> Yep >> > >> >> >> >>A little history >> >>================ >> > >> >[SNIP]. >> The issues raised here are hopefully covered off elsewhere. >> > >> >> >> >>To sum up >> >>========= >> >>To differentiate I want to add intelligence to my platform (effectively >> >>a gatekeeper). If I can't use fast setup as part of this people will >> >either use the direct call model, >> >>or use dumb gatekeepers. Basically the gatekeeper routed model will >> loose >> >out. >> > >> >Nothing you have described so far is either helped or hindered by >> >FastStart, this point is completely irrelevent. As I said above, >> >Intel >> >has always believed in the value of Gatekeepers to H.323 systems. I'm >> >surprised that you didn't present a contribution to provide >> >lightweight >> >'connection switching' in a general manner. >> The point really is that it has not helped...... >> > >> >> >> >>Hence I need fast setup to be useful for a gatekeeper adding >> intelligence, >> >which basically means being >> >>able to quickly break and make connections. >> > >> >This is great! If this is what you require, lets come to quick >> >agreement on >> >this and move on. >> > >> >> >> >>I have presented a solution that I believe meets these requirements. >> >>But if there is another way of meeting my requirements then I would be >> >only too happy to adopt it. >> >> >> > >> >Here are my suggestions that I _think_ provide the functionality you >> >desire: >> I think it's important that we try to sort out the problem we are >> solving first. If you feel we are on the same wavelength then we can >> move on to the technical implementation, but I don't think we are quite >> there yet. I hope this has helped. Besides, I would also like more >> time to think about what you have proposed. >> > >> > >> [SNIPPED, but not forgotten] >> > >> >Does this solve your issues? >> >> This is a good start and I'm confident that in a few rounds we can get >> there. Thanks for the time you've put into this Jim. You may not thank >> me now, but I'm sure that in a few years you (or your company) will >> thank me for bringing this all up!!!! (well say 10 years. Or not more >> than 20 years. Well not much more than 20 years....) >> > >> >Best Regards, >> >jimt. >> > >> >> Pete >> > >> >************************************************************************ >> >* >> >*** +1-503-264-8816(voice) +1-503-264-3485(fax) >> >*** >> >*** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. >> >*** >> >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** >> >************************************************************************ >> >* >> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neil Starkey, EVP/CTO nstarkey(a)databeam.com DataBeam Corporation http://www.databeam.com 230 Lexington Green Circle +1 606 425 3500 voice <<NEW ADDR/PHONE Lexington, KY 40503 +1 606 425 3528 fax <<NEW FAX ... no we didn't move - it's a conspiracy between the phone company and the post office! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0

Re: Bad Description Of Call Ref Value In H.323v2?
by Pete Cordell 11 Dec '97

11 Dec '97

Tom, CRV has a long and confusing history. Originally the CRV on the Q.931 parts and the RAS parts were intended to be the same. CRV along with CID were expected to be unique. We went for decision, and then it was found that multiple parties in a conference could potentially assign the same CRV. This wasn't really a problem for the Q.931 channel but was for a gatekeeper that was using this information to decide which record it was looking at. In Boulder srcCallSignalAddress was added into the SETUP message as part of the implementor's guide (v1.1 if you like) so that the combination of the CRV and srcCallSignalAddress could be used to identify a call. i.e. CRV was is a unique number generated by the uniquely addressed entity defined by srcCallSignalAddress. This worked for ARQ but since srcCallSignalAddress didn't appear in BRQ or DRQ it wasn't a complete solution. Hence if a called endpoint receives a call with a CRV that it is already using in a currently valid ARQ it has to generate a new and unique number. Hence CRV is different in the Q.931 and RAS channels. To try and tie it all back together again the CallIdentifier has been added in V2. So the short answer is that CRV in Q.931 and RAS may/will be different (assuming that was the question). Moral of the story.... little slips cause big problems, and slips do happen!!! So if you've got any free time (whatever that is!) please look at the draft and try to weed out any issues!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Tom Taylor[SMTP:Tom.Taylor.taylor@NT.COM] >Sent: 11 December 1997 13:00 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: FW: Bad Description Of Call Ref Value In H.323v2? > >There is a problem with the wording of H.323v2, Section 7.4, when it >talks about Call Reference Value. From the lack of reaction, I suspect >my earlier message did not go through. > >>-----Original Message----- >>From: Taylor, Tom (P.T.) >>Sent: Tuesday, November 11, 1997 3:33 PM >>To: 'itu-sg16(a)mailbag.intel.com' >>Subject: Bad Description Of Call Ref Value In H.323v2? >> >>Section 7.4 of H.323v2 talks about Call Reference Value as it appears in >>Q.931 and RAS messages. It indicates that the RAS channel itself has a CRV >>-- not true, surely. Perusal of H.225.0 makes clear that the CRVs in >>the RAS >>messages are copied from the Q.931 calls they are about, and are used to tie >>the RAS messaging to the latter. >

1 0

FW: Bad Description Of Call Ref Value In H.323v2?
by Tom Taylor 11 Dec '97

11 Dec '97

There is a problem with the wording of H.323v2, Section 7.4, when it talks about Call Reference Value. From the lack of reaction, I suspect my earlier message did not go through. >-----Original Message----- >From: Taylor, Tom (P.T.) >Sent: Tuesday, November 11, 1997 3:33 PM >To: 'itu-sg16(a)mailbag.intel.com' >Subject: Bad Description Of Call Ref Value In H.323v2? > >Section 7.4 of H.323v2 talks about Call Reference Value as it appears in >Q.931 and RAS messages. It indicates that the RAS channel itself has a CRV >-- not true, surely. Perusal of H.225.0 makes clear that the CRVs in the RAS >messages are copied from the Q.931 calls they are about, and are used to tie >the RAS messaging to the latter.

1 0

Re: (Resolution?) Limitation of nonStandardData
by Pete Cordell 11 Dec '97

11 Dec '97

Joerg, Obviously the IETF has not been too busy this time!!! I agree we have to say what to do if you want to insert nonStandardData when there is already some there. Unfortunately our application will break if the our nonStanadardData is not passed between co-operating gatekeepers. So I'm afraid we are 180 degrees out of phase with your proposed text!!! I had resolved that the nonStandardData from endpoints passed between my cooperating entities would use the nesting technique that I originally mentioned anyway. Basically if non extended nonStandardData is seen I would build it into a SEQUENCE like I originally proposed and then add the whole lot as a single item in the extended nonStandardParameter form. Because I am pretty sure of the entities I am talking to I can ensure that it is un-rolled properly. So my additional text would be: "If intermediate entities on the signalling path need to insert nonStandardData when there is already nonStandardData present that is not of the extended form described above (i.e. this sentence goes below what I originally presented, just avoid any confusion!) they are encouraged to take measures to ensure that the original nonStandardData can be recovered by entities further down the signalling path once those entities have removed any nonStandardData specific to them. This can be achieved by nesting the original nonStandardData field inside the nonStandardParameter created by the intermediate entity. However, endpoints should be aware that if they do not insert nonStandardData in the extended form it may be overwritten by intermediate signalling entities." The latter statement really conforms with Joerg's a) suggestion without using SHALL!!! Pete (P.S. The prize is a grammar checker, but it is still in the post!) ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@CS.TU-BERLIN.DE] >Sent: 11 December 1997 02:53 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: (Resolution?) Limitation of nonStandardData > >Pete and others, > >I have followed this discussion with some delay but eventually managed >to get through all the e-mails sent on this subject. Your final >suggestion looks good to me but I would want to include > >a) either a strong recommendation that endpoints SHALL use the new > parameter > >b) or -- if this is not possible because of our backward > compatibility vow in the ITU-T -- a statement that specifies what > an entity is supposed to do if it does receive a parameters that > does not follow this convention. > >Although we can assume that there are not too many implementations out >there doing this (probably people are still chewing on the base spec >:-), >completeness requires to define this behavior as well. > >> >> Some suitable text to cover this case may be: >> >> "To include multiple elements of nonStandardData in an H.225 message the >> nonStandardParameter SHALL BE in the following way. This special use of >> the nonStandardParameter is identified by setting the >> nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0) >> recommendation (0) h (8) 2250}. In this case the information contained >> in the data part of the nonStandardParameter SHALL CONSIST of a fragment >of >> ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the >> same as those for all H.225 messages). The ASN.1 fragment has the >> following syntax: >> >> ExtendNonStandard ::= SEQUENCE OF NonStandardParameter >> >> Entities SHOULD use this method for including >> nonStandardData in messages even if they only insert one piece of >> information as it allows other entities in the signalling path to either >> add or delete their own nonStandardData without overwriting information >> inserted by the originating entity." > >IF AN ENTITY RECEIVES A SIMPLE NonStandardParameter, IT SHALL NOT >MODIFY >OR MOVE ITS CONTENTS IN ANY WAY BUT PASS ON THE PARAMETER UNCHANGED. >IN THIS CASE, IT CANNOT ADD ITS OWN NonStandardParameter TO THE >MESSAGE. >AS A CONSEQUENCE, AN ENTITY SHALL NOT RELY ON NonStandardParameters TO >FUNCTION PROPERLY. > >IF AN ENTITY KNOWS THAT IT COMMUNICATES WITH A VERSION 1 ENTITY, IT >SHALL >NOT MAKE USE OF THIS MECHANISM. > >This is probably not yet the right (order of) wording but right now I >just >want to get across what I think should be added... > >> >> Apart from winning longest sentence of the year, how does this sound? >Good. And congratulations! What did you win? ;-) > >Joerg >

1 0

Re: (Resolution?) Limitation of nonStandardData
by Joerg Ott 11 Dec '97

11 Dec '97

Pete and others, I have followed this discussion with some delay but eventually managed to get through all the e-mails sent on this subject. Your final suggestion looks good to me but I would want to include a) either a strong recommendation that endpoints SHALL use the new parameter b) or -- if this is not possible because of our backward compatibility vow in the ITU-T -- a statement that specifies what an entity is supposed to do if it does receive a parameters that does not follow this convention. Although we can assume that there are not too many implementations out there doing this (probably people are still chewing on the base spec :-), completeness requires to define this behavior as well. > > Some suitable text to cover this case may be: > > "To include multiple elements of nonStandardData in an H.225 message the > nonStandardParameter SHALL BE in the following way. This special use of > the nonStandardParameter is identified by setting the > nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0) > recommendation (0) h (8) 2250}. In this case the information contained > in the data part of the nonStandardParameter SHALL CONSIST of a fragment of > ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the > same as those for all H.225 messages). The ASN.1 fragment has the > following syntax: > > ExtendNonStandard ::= SEQUENCE OF NonStandardParameter > > Entities SHOULD use this method for including > nonStandardData in messages even if they only insert one piece of > information as it allows other entities in the signalling path to either > add or delete their own nonStandardData without overwriting information > inserted by the originating entity." IF AN ENTITY RECEIVES A SIMPLE NonStandardParameter, IT SHALL NOT MODIFY OR MOVE ITS CONTENTS IN ANY WAY BUT PASS ON THE PARAMETER UNCHANGED. IN THIS CASE, IT CANNOT ADD ITS OWN NonStandardParameter TO THE MESSAGE. AS A CONSEQUENCE, AN ENTITY SHALL NOT RELY ON NonStandardParameters TO FUNCTION PROPERLY. IF AN ENTITY KNOWS THAT IT COMMUNICATES WITH A VERSION 1 ENTITY, IT SHALL NOT MAKE USE OF THIS MECHANISM. This is probably not yet the right (order of) wording but right now I just want to get across what I think should be added... > > Apart from winning longest sentence of the year, how does this sound? Good. And congratulations! What did you win? ;-) Joerg

1 0

Re: (Resolution?) Limitation of nonStandardData
by Pete Cordell 10 Dec '97

10 Dec '97

Dear All, After a tireless and exhaustive survey of vendors it appears that no one is using nonStandardData in a way that would cause problems with defining the piece of data that goes into the NonStandardParameter OCTET STRING as a SEQUENCE OF NonStandardParameter. Some suitable text to cover this case may be: "To include multiple elements of nonStandardData in an H.225 message the nonStandardParameter is used in the following way. This special use of the nonStandardParameter is identified by setting the nonStandardIdentifier to be an OBJECT IDENTIFIER of type {itu-t (0) recommendation (0) h (8) 2250}. In this case the information contained in the data part of the nonStandardParameter consists of a fragment of ASN.1 encoded into an OCTET STRING (The ASN.1 encoding rules are the same as those for all H.225 messages). The ASN.1 fragment has the following syntax: ExtendNonStandard ::= SEQUENCE OF NonStandardParameter It is recommended that entities use this method for including nonStandardData in messages even if they only insert one piece of information as it allows other entities in the signalling path to either add or delete their own nonStandardData without overwriting information inserted by the originating entity." Apart from winning longest sentence of the year, how does this sound? Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Pete Cordell[SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: 05 December 1997 13:53 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >The reason for my gymnastics is to give transparency to implementations >that already use nonStandardData and are already out there. A >gatekeeper that sees previousNonStandard (I've changed the name to >overWritten below in an attempt to increase the clarity) when it goes >to >remove its nonStandard part knows that an earlier gatekeeper in the >chain overwrote nonStandardData that wasn't in this form and so can >restore it as it was. This allows endpoints that are out there and >only >understand the data in the form that it presents it in can make use of >it. > >From a code impact point of view I see no difference between saying the >OCTET STRING is > >SEQUENCE OF NonStandardParameter, or > >SEQUENCE { overWritten NonStandardParameter OPTIONAL, extra SEQUENCE OF >NonStandardParameter } > >If you support the OID you have to write code either way. > >However, if nobody is using nonStandardData in the H.225 PDUs yet then >we are trying to solve a problem that doesn't exist. So the question >is: > >IS ANYBODY OUT THERE USING NONSTANDARDDATA AT THE MOMENT??? > >If not Jim's solution is fine. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>Sent: 05 December 1997 11:31 >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Re: Limitation of nonStandardData >> >>I rather thought that Jim's original solution, which is that we agree >>to >>get an OID which means "the OCTET STRING in the data part is actually a >>SEQUENCE OF NonStandardParameter" was simple and clean and totally >>compatible. (I don't really care whether it's SEQUENCE or SET). >> >>Is it possible just to write into the H.225/H.245 standards some OID >>which >>is actually within the tree of each standard and then add a single >>sentence >>to the standard which says something like "if the OID is xxxxxx then >>the >>data contains a sequence of NonStandardParameter." That's all. There is >>no >>compatibility problem, no one has to change code, that's all. If you >>don't >>need this OID then you don't use it. It doesn't need to change a line >>of >>anyone's code. Current implementations which don't recognize or send >>this >>OID work exactly as before. >> >>I would like to do this both in H.225 and H.245. In each case where the >>nonStandardData is not now a sequence, I may in the future want to pass >>some parameters through someone else's stack or through a cloud of >>gatekeepers. All this discussion about "I can think of a case where it >>won't work" are beside the point. The point is that I can think of >>situations where it will work, and right now I have no choice but to >>come >>to private agreements on what the OID will be. *This* is a pain, as >>well as >>making it very difficult to work with more than one other person. An >>agreement on a single OID will certainly improve useability and >>interoperability. >> >>I thought that it's much too late to muck about with the actual >>standards. >>Quite frankly, I am likely to object to the ASN.1 gymnastics suggested >>in >>other letters, because this is real new code and new state suggested in >>December when the thing is going to Decision in January! The simple >>suggestion that we add an OID to the tree of H.225 and H.245 surely >>solves >>the problem in a way which is just an "editorial change". And if it's >>too >>late even for this, then let's do nothing now and put it into VoIP or >>the >>implementor's guide. >> >>Sorry if this note sounds rushed -- I am busy preparing for a difficult >>IETF. >> >>Scott >> >

1 0

Re: Docs for Decision (H.245, H.235, H.246, H.323)
by Pete Cordell 10 Dec '97

10 Dec '97

Gary, Dale, Will we be determining anything at the Geneva meeting? We are looking at the idea of having the ability to open an HTTP logical channel as part of our future developments. This would be used to support the call centre environment among other things. At the most the thoughts are a bit patching and more work needs to be done over the future study period, but the idea would be to declare an HTTP transmit capability in the cap set. A server could then ask a client to open a HTTP session to a particular address using the RequestMode message which would contain a URL. Since HTTP transactions are typically not persistent, doing the OLC signalling does not seem appropriate. This might be controversial so it would be good to start getting people used to the idea!!! If no determination will be done, is it worth bringing things like this along as informational contributions? At some point we also want to get to grips with the intergatekeeper stuff. We see this as particularly useful for instances of 'trunking' between gatekeepers and between gatekeepers and large gateways. Also, what time frame would we be talking about for these sorts of additions in the next release? I suppose one affects H.245 and the other H.323/H.225. Thanks, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Gary Thom[SMTP:gthom@DELTA-INFO.COM] >Sent: 10 December 1997 15:27 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Docs for Decision (H.245, H.235, H.246, H.323) > >Hi All, > >The Jan/Feb SG16 meeting is drawing near. > >Several recommendations are up for Decision at this meeting. In >preparing for the meeting, I have asked the editors of the Q14 >recommendations to collect any changes to the White Contributions in a >"Change Document" that can be submitedt to the SG16 meeting as a >Delayed >Contribution or a Temporary Document. > >Hopefully, any changes are minor or editorial. I do not know of any >large or controversial issues. > >We need to submit these "Change Documents" about two weeks before the >meeting so that they will be distributed as Delayed Contributions. If >we >then review/approve the change documents at the WP2 Plenary on Monday >Jan 26, we should be able to have them approved at the Tues SG16 >Plenary. > >Editorial or typographical corrections should be sent directly to the >editor. Any more significant changes should be discussed and agreed to >on the reflector. These more significant changes should be limited to >fixing things that are broken, and not propose new functionality. > >My goal is to sort out any controversial issues before we go to Geneva, >and if necessary have a short, complete change document that everyone >can agree, so that we can easily Decide the new recommendations. > > >Gary > >------------------------------------------------------ >Name : Gary A. Thom >Company: Delta Information Systems, Inc. >Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA >Phone : +1-215-657-5270 Fax : +1-215-657-5273 >E-mail : gthom(a)delta-info.com >------------------------------------------------------ > >---------------End of Original Message----------------- > >------------------------------------------------------ >Name : Gary A. Thom >Company: Delta Information Systems, Inc. >Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA >Phone : +1-215-657-5270 Fax : +1-215-657-5273 >E-mail : gthom(a)delta-info.com >------------------------------------------------------ >

2 1

Re: Pete Cordell's FastStart issues
by Pete Cordell 10 Dec '97

10 Dec '97

Jim, You've definitely captured the core technical functionality required. I was hoping to get you to appreciate the big picture behind the technical details so that you can understand why they are so important. It's at this level we are perhaps not agreeing. But still, maybe that doesn't matter so let's get on with looking for a technical solution. I note your comments below. Although I don't entirely agree with them on all counts, one of the wonders of the English language is that different people can get different meanings from the same piece of text. So if we can agree that we understood different things from the text, we can move on... Firstly I'm worried about sending multiple call proceedings/alertings to an endpoint. Conceivably we could get the case that we receive a call proceeding after alerting for example. This is definitely not valid Q.931. We could say that any endpoint that accepts fastStart should be able to cope with this case, but this involves multiple modifications to the Q.931/H.225 state machine which I feel is undesirable. User invitation and media establishment are in many respects orthogonal and so making media negotiation conform to the invitation sequence is tying one arm behind your back. What would be your comments if I suggested moving the fastCaps stuff to the H323-UU-PDU field? This would allow us to send the messages at any time (via FACILITY if necessary) without affecting the Q.931 sequence and state. This should be OK as this is what is being used for supplementary services. If this approach doesn't work then we have a major problem, so any issues with it need to be raised!!! I'm also thinking about how the gatekeeper will transfer the capabilities through itself. It will have to decode the messages (e.g. setup) so that it can find the relevant information. It may then have to change some of the fields before passing the message on. This will mean re-encoding the message. If there is a mis-match in the version of Capability supported by the endpoint and the gatekeeper then capability information will get lost in this process. This means that endpoints will not be able to achieve end-to-end negotiation of caps, and any new codecs added by vendors will not be usable in this configuration. As I envision faster evolution in the endpoint arena this seems a very real proposition. To get around this problem it may be best to include the capability information as an OCTET STRING. This allows the gatekeeper to look at it, but also allows it to insert the information into an outgoing message without having to have decoded it and re-encoded it (i.e. it is just a copy operation) and so no information is lost. I hope this moves us forward and not backwards!!! I look forward to your comments, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] >Sent: 09 December 1997 01:48 >To: pete.cordell(a)bt-sys.bt.co.uk; itu-sg16(a)mailbag.jf.intel.com >Subject: Re: Pete Cordell's FastStart issues > >Pete, > >Thanks for you response. It looks like you have articulated some >useful >functionality >in the ability to quickly switch media channels, but this is orthogonal >to >the FastStart sequence. > >I would be very interested in pursuing a light weight media switching >in >_all_ cases, independant >of FastStart or any other control establishment that exists in H.323. > >I have tried to clarify and corrected some of your statements by >referencing APC documents and presume >that we are getting to the same 'wavelength'. > > >Best Regards, >jimt. > > > >> -----Original Message----- >> From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk] >> Sent: Monday, December 08, 1997 9:16 AM >> Subject: RE: Pete Cordell's FastStart issues >> >> Jim et al., >> >> I'm glad we've got a discussion going on this. This seems to be a >> really big issue that can have a major impact on the future of H.323. I >> know we're all really busy, but come January we will be stuck with what >> ever we decide, so I'm hoping that other people can jump in here to >> thrash out the issues as much as possible. The more input, the better >> the solution is likely to be. > >To be honest, it looks like H.323 is having a serious impact even >without >V2..... :-) > >> >> I've put comments in below. From the comments presented though I don't >> think we are on the same wavelength yet, so most of the comments are >> related to the problem space rather than any solutions. > >I thought we had agreement. The functionality that you would like is >the >ability to >break and re-make 'connections' in a lightweight manner. >(which I still assume are media channels, unless you tell me >otherwise...) > >> >> Pete >> ================================> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================> >> >> >---------- >> >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] >> >Sent: 07 December 1997 19:18 >> >Subject: Re:Pete Cordell's FastStart issues >> > >> >Pete, (and others) >> > >> >Let me try and respond to your issues and hopefully we can resolve this >> >in a relatively concise manner. Before we get started though I would like >> >to make a couple of points clear: >> > >> >Recall that the "fast start" problem as stated previous to the Israel >> >meeting and formalized in the contribution to that meeting, was the >> >following. To provide a minimal round trip time connection sequence, >> >for simple constrained calling scenarios. The requirement was to have >> >minmal engineering impact to current shipping products and complete >backward >> >compatability. > >> I've looked through my notes and I can see any authoritative, exclusive >> list of what the fast start should be expected to solve. I don't see >> anything that said it should be restricted to "simple constrained >> calling scenarios". > >There were verbal discussions before Israel, these were formalized in >APC-1187 with the text: > >"Specifically with audio-only being the base system requirement, many >current implementations >are operating in this manner on the Internet. These environments >provide >many challenges to the >implementers of these systems with regard to transmission delay, >transport >jitter, and overall reliability. >Most if not all of these issues have been designed around by the >developers, however there is >one element that is inherent in the protocol and cannot be avoided; >startup >time. > >The number of RTT (round-trip-times) that occur in the normal startup >of an >H.323 call is typically >4 by the time the first media channel is open, assuming that both ends >are >truly asynchronous. >(Setup-Connect, Cap Sets, M/S, OLC). On the Internet, this number of >RTTs >can lead to very long >connect times, independent of the quality of the implementation. Users >expectations >(such as those using H.323 for Internet-telephony) may never be met in >some >situations. >The solution to this, is to simply cut down on the number of RTTs - an >optimal number would be 1. > >The idea is to provide a mechanism by which an H.323 terminal could >call >another terminal and operate >in a fast mode (i.e. audio only) using only the Setup-Connect >sequence. >The called terminal >would always have the option of refusing this fast mode and >continuing >in the standard manner." > >This same text was in APC-1306 at Sun River and was approved without >changes. > > >> > >> >I have always been a proponent of Gatekeepers and the functionality, >> >features, and services that they can provide. >> > >> >Everyone (including you), supported the final version of FastStart >> >which came out SunRiver with the additions of bi-directional capabilities. >> >With the presentation of your alternative approach there was never any >clear >> >motivation for developing the more complicated version other than you >> >'didn't like' the current form. I'm happy to see you've presented a >> >real issue to which you would like a solution. >> > >> >I would like codify my understanding of your issues and see if we can >> >find a solution to them. I _think _you imply the need for a low overhead >> >'mode switch' which really has nothing to do with FastStart, but let me >see >> >if I understand your points. > >> To me connection setup (i.e. user-to-user connection) is pretty much all >> that H.323 is about. Once a connection is setup there is little more >> for H.323 to do, other than tear-down. > > >I'm still confused by what you mean by connection. By 'call startup' >what >is meant in the above >APC's is the point at which the caller and callee can begin exchanging >media. > >> > >> > >> >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote: >> >[SNIP] >> >> Each user has an account on the system. They can use >> >>it as a single number by which to contact them by. As you move from >> >office to home to mobile, you configure it using a web browser with >> >>the number to contact you on. People trying to contact you dial a >> >>single number and the platform forwards the call to the correct location. >> >> It also allows people to leave voice messages on the system. >> >>Additionally you can configure it to do things like try the office phone >> >>first, then the mobile and if that doesn't work leave a message. This >> >>sort of flexibility is not easily addressed by a directory. It >> >>can also receive e-mails and faxes etc. >> >> >> >[SNIP] >> > >> >>This is admittedly not rocket science, and you've probably come across >> >>services like this already. Our job is to move this to the IP world. >> > >> >Why can't you can accomplish this today (in R2) with the multiple alias >> >registrations (that fact that you may use WEB front end is irrelevent)? >> >The Gatekeeper then has his 'rotary switch' of locations to look >>through to >> >find the current active location. This is much like (if not exactly) >> >VocalTec's CMA architecture. > >> Your right, the configuration side of things is not the issue. > >> > >> >>Product Impact >> >>=============> >>To understand the impact of this on the protocol, >>let's look at the case >> >>of using a search algorithm to look for a user and also returning a call >> >>after interrogating the voice bank. >> >> >> > >> >Tying user-network signalling to network-network signalling in the >> >protocol is bad practice, limiting and cumbersome. > >> I agree, network-network signalling is for another day. However this >> issue is very much in the user-network signalling area. The issues >> remain even if only one gatekeeper is involved (which hopefully implies >> that there is no network-network signalling). > >I still don't think we want to burden the endpoints with a 'search >algorithm to look for a user'. >The user-network signaling is contained in the ACF (or perhaps a GK >routed >Setup) anything >more complicated seems a lot like network-network signalling. (Or at >least >for further study :-) ) > >> > >> >>Let's assume the system is configured to contact my work number first >> >>and them my mobile number. In this case the final connected endpoint is >> >> not known until the CONNECT message is received. Hence the >> >>capabilities of the endpoint you will be talking to are not known for >> >>sure until you get CONNECT. >> > >> >I see this, and agree it is entirely true. It has no effect however on >> >the the capabilities of the _calling_ party. They _are_ known, and there >> >is no reason why the possibile capabilities should change. > >> Correct > >> > >> >>This is not a problem with the basic call setup sequence as the H.245 is >> >>not established until after CONNECT. >> > >> >This is not quite true. There has been the ability (since 3/96) to >> >start H.245 at any point after the SETUP message is received. This >required >> >two things, which by the way would be required in all of these scenarios. >> > >> >The caller and callee has to be able to deal with H.245 and possibly >> >media, 'early'. The caller has to place the H.245 port in the Setup >message. >> >(Alternatively the callee can place the H.245 port in the Call >> >Proceeding/Alerting message) > >> True, but hopefully you'll agree with me that in this case the >> gatekeeper could delete any H.245 addresses from messages other than >> CONNECT and it would get the desired behaviour. > >As you point out, the Gatekeeper has full control. In fact it can >enable >or disable the FastConnect >sequence as well. > >>This seems to be a pretty NULL operation as nobody seems to be sending >H.245 addresses in >> messages other than connect anyway. > >Exactly point the point I made below concerning the Facility message. >Endpoint manufactures >would like to have the option of a low impact, one roundtrip connect >sequence. > >> > >> >>However, with fast connect we want to start capability negotiation as >> >>soon as possible, and are not able to wait until CONNECT. >> > >> >The Determined version of FastStart DOES do a full capability exchange >> >before the CONNECT. (althought it does not provide for an iterative >> >_negototiation_, as this defeats the Fast portion of FastStart). > >> I have problems with saying the FastStart shall be 1 round trip or bust. >> The intent seems to have been that a minimum of round trips should be >> used compatible with negotiation, security etc. If a particular case >> requires an extra round trip, then that is the minimum number of round >> trips that case can be set up in. That doesn't break fastStart. I >> would say it's good because it has meant that we don't fall back to the >> 6 1/2 round trips that we typically need. > >No, actually the original intent (see above) was to establish a one >round >trip method. >The negotiation is poorly termed it really should be called >'capabilities >exchange'. >Both this, and security require no extra messages or round trips. > >> > >> >>This also has the benefits that we can listen to announcements prior to >> >>the CONNECT message (such as "The number you have dialled has >> >>changed, but we are re-routing you anyway"). >> > >> >This is EXACTLY what FastStart provides as soon as the Setup is >> >recieved, the recipient may start playing media back to the caller. The >caller >> >may be constrained from sending media to the callee until the Connect is >> >received - just as it works in the circuit world. > >> I was trying to capture the issues here, not saying that the current >> fast start doesn't meet any of them. Basically we have conflicting >> requirements here 1) we want to establish media prior to CONNECT to >> allow announcements, 2) we want to delay establishing media until after >> CONNECT so that the gatekeeper can do some intelligent stuff. This is >> what makes this topic so interesting!!!! > >Seems like you _have_ established the media stream back to the caller; >it is >just that you are switching the ultimate source of that media. In the >case >you >describe, it seems like you want the protocol signalling to be aware of >this - >I'm not sure why. > >> > >> >>However, if the system gives up ringing my work number and then tries >> >>the mobile number, it has to present a new set of capabilities to the >> >calling endpoint. >> > >> >That is true, and this can occur by simply sending another Call >> >Proceeding message (or Alerting) with the new caps. There is no need >however for >> >the _caller_ change or otherwise resend its caps..... In other words the >> >Gatekeeper will still be presenting the same set to the subsequent >> >callees as it polls them. > >> You're right that the caller does not have to generate new caps. >> However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint >> breaks H.225, and so would not be backwards compatible. > >Why does it break H.225.0? FastStart will not be supported by Rev1 >endpoints in any case >which is why there is backward compatible signalling. >> > >> >>Now I'm in the mode of interrogating the voice messages that have been >> >>left for me. My endpoint is connected to the sub-system that plays out >> >>the recorded messages and it asks me if I want to return the >> >>call. To do this the system needs to create an outgoing call, and >> >>locally generate a ringing tone. When the remote party answers the two >> >>endpoints need to be connected together. >> > >> >This is either some form of a transfer (from a protocol point of view) >> >or shouldn't it be hidden from the endpoint in terms of signalling? > >> In a distributed world there is only so much that you can hide from an >> endpoint. That's why this topic is so important. To roll out customer >> friendly services the endpoints need to support some basic capabilities. >> Hopefully this is worth endpoint vendors doing as useful services mean >> that people can use there endpoints for more things. Thus the >> technology is more likely to catch on, than if you are only likely to >> get reasonable service from a call centre via good old POTS. > >It would seem to me that endpoint vendors would make a trade-off on >what >customers request for functionality vs the general industry support and >ease of implementation >of that functionality. > >I do know of one vendor :-) that is interested in making sure that >rolling >out of "customer friendly services" >is possible, and for customers to utilize endpoints for more "things". > >> > >> >>You may say that the FACILITY message could be used to do this. However, >> >>the caller has state stored >> >>in the platform/gatekeeper (such as where they are in the menus etc.) so >> >>that when they finish this new call they can go back to interrogating >their messages. >> >>This would not be possible with the FACILITY approach. >> > >> >It would seem that exposing this bookkeeping/signalling would require a >> >_large_ commitment on the part of all the endpoint manufacturers - >> >wouldn't it be better to provide this in an 'invisible' way? Aside from >the >> >complexity/compatibiliy issues it provides for product differentiation. > >> I think you're agreeing with me that the FACILITY way is a bad way to go. > >> > >> >> >> >>WOW that's complicated!!! >> >>========================> >>At first sight this appears horrendous, >>but in actual fact it is quite >> >>simple. All it requires is for the platform/gatekeeper to be able to >> >break connections and re-establish >> >>new connections when it wants to. >> > >> >AAHHH.... so this is what you wanted! This _does_ seem like a >> >'transfer' type of thing, in any case it would appear to be >>independant of >> >FastStart. > >> A setup is almost invariably part of transfer, so I don't see that you >> can call them independent. Anyway, the report from Hertzliya says >> support for supplementary services should be included in fast setup. > >Actually the meeting report said just the opposite. In APC-1249 (the >meeting report) on page 8 it says > >"A. Supplementary services must consider fast cut-thru, and...." > > >A Setup is invariably part of transfer, but only if that transfer >envolves >the _control channel_. >It is not clear that you wanted this, I thought we were talking about >media. During your sequence does >the Gatekeeper 'get out of the way' when the final endpoint is found? >Or >for the duration of the call >does the Gatekeeper act as a 'proxy' for the other endpoint ? (i.e. >stay in >the Gatekeeper routed model) > >> > >> >I have to admit, I'm not sure what you mean by 'connection' though. Is >> >this simply logical media channels, or is it a larger concept? > >> I'm really mean establishing some sort of media exchange between users >> such as audio or video. > >OK, so OpenLogicalChannels, not establishing H.225.0 or H.245? > >> > >> >[SNIP] >> > >> >> >> >>So where's the problem >> >>=====================> >>The problem is that I can not make use of >>the fast setup scheme with >> >>these services, because it does not support the break and make >> capability. >> > >> >This is _new_ functionality that was never listed as a requirement of >> >FastStart, and I would argue that 'breaking and making connections' >> >goes against the scope of the FastStart usefulness. >> This is where I totally disagree. The list of fast start requirements >> was never exclusive. We announced our requirements for fast start and >> no body objected to them, and some even backed them up. If you had >> objections you should have raised them at the time. >> > >> >>To do these services I need tofall back to H.245. If the >> >>standard setup is not good enough for a basic point-to-point call then >> >>it is not good enough for entities that introduce intelligence which in >> >>fact have more stringent timing >> >>requirements because the breaks and makes are more difficult to conceal >> >under things like ringing. >> > >> >The 'standard setup' is no way "not good enough" for basic >> >point-to-point operation. It simply as case that in certain well >defined (resources >> >and entities known) that optimizations can and should be made to >>operate in >> >simple low delay environments. >> > >> >>Assuming that the reason for implementing the gatekeeper routed model is >> >>to add these sorts of features, then really the gatekeeper routed model >becomes a second class citizen. This >> >>is a problem for us. >> > >> >The Gatekeeper should most definitely NOT be constrained from adding >> >features and providing expanded services. The Gatekeeper routed model >> >was specifically developed to hide this complexities from the >>endpoints, in >> >fact the endpoint cannot even tell which mode it is running in other >> >than a bit in the ACF. >> > >> >The Gatekeeper is no more or less a "second class citizen" with >> >FastStart as with the 'standard' signaling. In fact I believe that it >has even >> >more control, because it may provide an asymmetrical connection on either >> >side of itself forcing either the caller or callee into a particular >mode of >> >operation. > >> If the standard startup is good enough then we seem to be taking >> elaborate measures to tune the efficiency of the "standard setup". > >In general, you can either have it 'fast' or you can have 'powerful and >flexible'. >I'm not implying at all that it should be an either/or situation. Why >do >we allow different >media codecs? Some modes are better for one situation, some are better >for >others. > >> Either the standard setup is good enough or it isn't. If it is good >> enough then we don't need fast start. I happen to think that it is not >> good enough. Hence we need a solution that is good enough for the basic >> call model and is also good enough for those of us that want to add >> value. If we don't achieve this, then as far as I can see the >> gatekeeper routed model can only become a second class citizen. > >I just don't understand this statement. The basis for being a 'second >class citizen' seems >to be that Gatekeepers don't have a special mode to swap media channels >which no other entity >has either. Again, this just seems to be completely orthonganl to >FastStart. > >> > >> >> >> >>Where to go next >> >>===============> >>To do what I need to do, I need a fast method for >>making and breaking >> >>connections without first establishing the TCP connection, negotiating >> >>caps, MSD, OLC, OLC ACK, >> >>and then sending media. We could achieve this by adding a break command >> >>to the FACILITY message and then having the ability to send new >> >>fastCaps at any time to make a new connection. This seems a minimal >> >>change from where we are at the moment and such a change would be fine >> >>by me. >> > >> >Again I'm not clear on what you mean by 'connections', but assuming >> >that you mean something like an audio channel (say 711-->723.1) than I >think >> >there are a number of fine options we can pursue. (for example H.245 >> >has established a 're-open' command.) >> > >> >> >> >>However, I know that Glen is interested in always running an MC, so he >> >>would want to add extra features. Others will probably also want >>features >> >>that have been carefully crafted >> >>into H.245. As a result we are likely to get feature creep so that more >> >and more H.245 functionality is put into H.225. >> > >> >I completely agree that it would be a very bad thing to re-invent H.245 >within H.225.0. >> > >> >> I also have concerns about having two ways and two APIs (fast and slow) >> >> for doing things. This explains my attempt to re-use as much of H.245 >as possible. >> > >> >To pick a nit, we're not talking about API's; there is one way within >> >the protocol to establish an H.245 connection. If you need these >>features, >> >flexibility and control; this is what you should do. That being said >> >there are two forms of Setup/Connect messages for those >> >Endpoints/Gatekeepers/MCUs that would like to utilize them. > >> To pick more nits ( :-) ), we at some point have to build what we >> propose. Therefore, we can not conceive of protocols in isolation of >> how we will build them. If one protocol idea is easier to develop than >> another then we should go with that one. So although the ITU is not >> bothered with APIs, we as contributors, should be. >> >> Most stacks that I am aware of separate out the Q.931 part and the H.245 >> part. At the moment the H.245 part knows about caps and the Q.931 part >> does not. To put caps in Q.931 we need to put an API on the Q.931 part >> that accepts caps. Therefore we really do have two APIs, which is an >> issue. > >I can't comment on your development environment or platform, I only >know it is >not an issue in many of the currently shipping products. > >> > >> >> >> >>But let me reassure you I have no requirement to use H.245! I have a >> >>requirement to solve the problem presented above. >> > >> >The problem is to 'break and make' connections with minimal >> >overhead?..... > >> Yep > >> > >> >> >> >>A little history >> >>===============> > >> >[SNIP]. >> The issues raised here are hopefully covered off elsewhere. >> > >> >> >> >>To sum up >> >>========> >>To differentiate I want to add intelligence to my >>platform (effectively >> >>a gatekeeper). If I can't use fast setup as part of this people will >> >>either use the direct call model, >> >>or use dumb gatekeepers. Basically the gatekeeper routed model will >>loose >> >out. >> > >> >Nothing you have described so far is either helped or hindered by >> >FastStart, this point is completely irrelevent. As I said above, >> >Intel has always believed in the value of Gatekeepers to H.323 systems. >I'm >> >surprised that you didn't present a contribution to provide >> >lightweight 'connection switching' in a general manner. > >> The point really is that it has not helped...... > >> > >> >> >> >>Hence I need fast setup to be useful for a gatekeeper adding >> >>intelligence, which basically means being >> >>able to quickly break and make connections. >> > >> >This is great! If this is what you require, lets come to quick >> >agreement on this and move on. >> > >> >> >> >>I have presented a solution that I believe meets these requirements. >> >>But if there is another way of meeting my requirements then I would be >> >only too happy to adopt it. >> >> >> > >> >Here are my suggestions that I _think_ provide the functionality you >> >desire: >> I think it's important that we try to sort out the problem we are >> solving first. If you feel we are on the same wavelength then we can >> move on to the technical implementation, but I don't think we are quite >> there yet. I hope this has helped. Besides, I would also like more >> time to think about what you have proposed. >> > >> > >> [SNIPPED, but not forgotten] >> > >> >Does this solve your issues? >> >> This is a good start and I'm confident that in a few rounds we can get >> there. Thanks for the time you've put into this Jim. You may not thank >> me now, but I'm sure that in a few years you (or your company) will >> thank me for bringing this all up!!!! (well say 10 years. Or not more >> than 20 years. Well not much more than 20 years....) > >Let's keep slogging away, You know I'll always thank you Pete... :-) >I'm hoping that I have picked the issue that you would like to solve >and that >one of the previous solutions works for you. > >> > >> >Best Regards, >> >jimt. >> > >> >> Pete >> > > > >************************************************************************ >* >*** +1-503-264-8816(voice) +1-503-264-3485(fax) >*** >*** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. >*** >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** >************************************************************************ >* >

1 0

Docs for Decision (H.245, H.235, H.246, H.323)
by Gary Thom 10 Dec '97

10 Dec '97

Hi All, The Jan/Feb SG16 meeting is drawing near. Several recommendations are up for Decision at this meeting. In preparing for the meeting, I have asked the editors of the Q14 recommendations to collect any changes to the White Contributions in a "Change Document" that can be submitedt to the SG16 meeting as a Delayed Contribution or a Temporary Document. Hopefully, any changes are minor or editorial. I do not know of any large or controversial issues. We need to submit these "Change Documents" about two weeks before the meeting so that they will be distributed as Delayed Contributions. If we then review/approve the change documents at the WP2 Plenary on Monday Jan 26, we should be able to have them approved at the Tues SG16 Plenary. Editorial or typographical corrections should be sent directly to the editor. Any more significant changes should be discussed and agreed to on the reflector. These more significant changes should be limited to fixing things that are broken, and not propose new functionality. My goal is to sort out any controversial issues before we go to Geneva, and if necessary have a short, complete change document that everyone can agree, so that we can easily Decide the new recommendations. Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------ ---------------End of Original Message----------------- ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

1 0

Re: Remarks on H.450.x and H.225.0
by Callaghan, Robert 09 Dec '97

09 Dec '97

Ami, I fully agree with you. I saw nothing that could not be done using H.224.0 and H.450. However, I do agree that this does not align with "lite". The trade-off between "rich and fully featured" and "lite" is very important. An open discussion might lead to an understanding. Bob -------------------------------------- Robert Callaghan Siemens Business Communication Systems Email: Robert.Callaghan(a)Siemenscom.com Tel: +1.561.997.3756 >-----Original Message----- >From: Ami Amir [SMTP:amir@RADVISION.RAD.CO.IL] >Sent: Tuesday, December 09, 1997 4:42 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Remarks on H.450.x and H.225.0 > >Hi Pete and Friends > >A few points > >1. Granted that the "semi indirect" routed model (H.245 direct and >Q.931 indirect) was defered for further study - but this should not >prclude this mode. There are obvious advantages (in large networks) for >such a model. My recollection is that we never had the time or >inclination to look seriously at this model. > >2. H.323 seems to be too heavy for some applications (re- the IETF >SIP effort) , and not rich enough for others. We are constantly hearing >comments (e.g from chip manufacturers) that the code is too big, and >from others (e.g. PBX manufacturers) that essential features are >missing. > >I am proposing that we schedule time - say 1 day - (either at Geneva or >the folllowing Experts Group meeting) to discuss general directions for >future work. This would require some preliminary papers and >presentations from interested parties. > >What is the Group's feeling about this? > >Ami > >Pete Cordell wrote: > >> Orit, >> >> Sorry for the delay in this mail. >> >> On your topic 4, I would be worried about adding another call model. >> We >> already have the direct model, VocalTec's model (I couldn't think of a >> >> better way to describe it!) and the gatekeeper routed model. Adding a >> >> half gatekeeper routed model would further complicate things. >> Efficiency is good, but in general I think that generality is better. >> It's rare that you get a optimal general solution and I think that >> this >> is a case in point. I am also worried about bringing the other call >> model back into play because I can't remember why we disallowed it. >> I'm >> sure it must have been for a good reason, and just because I can't >> remember why doesn't mean the problem has gone away!!! >> >> One reason for reducing the number of models is so that modelling the >> way new features will act is much easier. >> >> Another issue is that the FACILITY-UUIE method of re-directing calls >> is >> already in use. Adding the H245Address to the FACILITY-UUIE seems to >> imply that the handling of the message should be different if you get >> one with an H.245 address in (i.e. if there is an H.245 address in it >> you simply connect using H.245 rather than the H.225 SETUP etc). This >> >> would produce backwards compatibility problems. Even if it weren't a >> backwards compatibility issue I think the simpler case of always using >> >> the H.225 SETUP is a better way of going because the signalling is >> simpler and cleaner. >> >> I hope this helps, >> >> Pete >> ================================= >> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================= >> >> >---------- >> >From: Orit Levin[SMTP:orit@RADVISION.COM] >> >Sent: 02 December 1997 21:18 >> >To: ITU-SG16(a)MAILBAG.INTEL.COM >> >Subject: FW: Remarks on H.450.x and H.225.0 >> > >> >Dear Pete and all others ! >> >My additional comments are below: >> > >> >>3. H.225.0 Annex H - ASN.1 >> >>All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. >> > >> > >> ----------------------------------------------------------------------- >> >> >------------- >> >We agree with Pete's proposal. It is more general but requires more >> >changes in the standard. Let fix it one way or another, but till >> >Geneva! >> >------- >> ---------------------------------------------------------------- >> >------------- >> >> >> >>4. H.450.2 Clause 10.6.1.1 >> >>This clause is talking about Call Transferring in case of GK Call >> >>Routed model and both Q.931 Signaling and H.245 protocol are >> "routed" >> >>by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >> >>Signaling is routed by the GK, but H.245 messages flow directly is >> >>legal and more efficient. It seems that the clause above doesn't >> cover >> >>this case. In order to provide a working solution for this case, an >> >>additional OPTIOANAL field "h245Address" should be added to >> >>Facility-UUIE message ... >> > >> > >> ----------------------------------------------------------------------- >> >> >------------- >> >Three things on this: >> >Firstly, Pete, you are right about the "future study". Still this >> mode >> >is more efficient and we shouldn't cancel it without serious >> >considerations. In this case (of H.450.2) with this optional field >> we >> >could support it. Do we want to cancel the possibility of using this >> >> >mode without even studying it ? >> >Secondly, the facility message, described in H.450.2 section, may >> >contain Facility-UUIE as a part of it. Currently this Facility-UUIE >> is >> >empty, but it can be used and have a new h245Address field. >> >Thirdly, I will try to explain the relevant scenario using H.450.2 >> >terminology. Suppose, A and B are in the GK routed call, while H.245 >> >> >and UDP streams flow directly between them. All "transferring logic" >> is >> >performed by the GK on behalf of B. None of the mentioned messages >> >(specifically CONNECT message) reaches B. Still, when the call is >> >transferred from A to C, B has to receive (a new) H.245 address of C. >> >> >The proposed way to receive it, is by means of FACILITY message >> >containing Facility-UUIE. Pay attention that B, who doesn't perform >> the >> >"transferring logic" itself, upon arrival of the FACILITY message >> >containing a new H.245 address, has to close the old H.245 channel >> and >> >open a new one (towards C). >> >--------------------------- >> -------------------------------------------- >> >------------- >> > >> >(I am starting to enjoy it, but I am serious.) >> > >> >>>Thanks, >> >> >> >>Orit Levin >> >>RADVision Inc. E Mail: orit(a)radvision.com >> >>575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. >> 230 >> >>Mahwah, NJ 07430 Fax: 201-529-3516 >> >> >> >

1 0

Update draft of H.bmultipoint
by Hidenobu Harasaki 09 Dec '97

09 Dec '97

Dear Ms. Li Yan, Mr. Sakae Okubo and other Q.12/16 experts, Thank you for your contribution for H.bmultipoint. Updated draft of H.bmultipoint (Version 1.1) is now available on ftp.gctech.co.jp incoming directory. Filename is "hbmult-v11.doc". The cover page of the file is attached below. I greatly count on expert's contribution to finalize the draft. Best regards, Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232 ------------------------------------------------------------------------ This draft is H.bmultipoint version 1.1, which is an updated version of Version 1 presented at Sunriver meeting. During Sunriver meeting, the following comments or suggestions were raised. 1. Delete "using H.246 gateways" from the second sentence and to describe in Section 9 a couple of possibilities; use of H.246 functions, use of interopration mode, transcoding, etc. It was also suggested to focus on H.320 as a typical case of other H-series terminals. 2. Dynamic VC change (i.e. between a multicast leaf and a point-to-point party when the current speaker switches) may be expensive and suffer noticeable delay. Since VC setup is not designed to guarantee to work in a real-time fashion. it needs some time (It could be 1.5 -20 seconds was mentioned). 3. Include system configuration of H.bmultipoint MCU as in H.231. 4. Include reference to service Recommendations such as F.700, F.710, F.720. 5. Concentrate on multicast by MCU and multicast by the root MCU initiated join. 6. Editor can use existing texts in H.140, H.231/H.243 and other related exiting Recommendations. 7. Tables 1 and 2 for master-slave determination need correction. 8. The next draft of H.bmultipoint will include the following implementation alternatives as information: remultiplexing, transcoding, use of layered coding, and use of H.320/H.321 interoperation mode. The editor needs expert's assistances to reflect some of the above comments or suggestions, and to fill the blanks in the draft Recommendatation. * Specific text referring to F.700, F.710 and F.720, and where the text should be inserted. * Is there any solution to cope with the problem No. 2 above? * In Section 6, call setup/release scenario is exactly the same as H.310 except point-to-multipoint audiovisual connection setup procedure. How a terminal can join a conference as a multicast leaf using H.245 negotiation? If the terminal is ROT, the MCU can automatically invite it as a multicast leaf. But considering the case of RAST, do we need to add H.245 message? Or, the terminal shall be declare that I'm a ROT? * Chapter 5 shall be a general system description, while chapter 7 explicitly specifies how the MCU behave. What are the essential specifications in Chapter 7? Any contributions toward the determination in January 1998 are solicited. Hidenobu Harasaki (harasaki(a)ccm.cl.nec.co.jp) editor for H.bmultipoint ------------------------------------------------------------------------

1 0

Re: Remarks on H.450.x and H.225.0
by Pete Cordell 09 Dec '97

09 Dec '97

Orit, Sorry for the delay in this mail. On your topic 4, I would be worried about adding another call model. We already have the direct model, VocalTec's model (I couldn't think of a better way to describe it!) and the gatekeeper routed model. Adding a half gatekeeper routed model would further complicate things. Efficiency is good, but in general I think that generality is better. It's rare that you get a optimal general solution and I think that this is a case in point. I am also worried about bringing the other call model back into play because I can't remember why we disallowed it. I'm sure it must have been for a good reason, and just because I can't remember why doesn't mean the problem has gone away!!! One reason for reducing the number of models is so that modelling the way new features will act is much easier. Another issue is that the FACILITY-UUIE method of re-directing calls is already in use. Adding the H245Address to the FACILITY-UUIE seems to imply that the handling of the message should be different if you get one with an H.245 address in (i.e. if there is an H.245 address in it you simply connect using H.245 rather than the H.225 SETUP etc). This would produce backwards compatibility problems. Even if it weren't a backwards compatibility issue I think the simpler case of always using the H.225 SETUP is a better way of going because the signalling is simpler and cleaner. I hope this helps, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Orit Levin[SMTP:orit@RADVISION.COM] >Sent: 02 December 1997 21:18 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: FW: Remarks on H.450.x and H.225.0 > >Dear Pete and all others ! >My additional comments are below: > >>3. H.225.0 Annex H - ASN.1 >>All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. > >------------------------------------------------------------------------ >------------- >We agree with Pete's proposal. It is more general but requires more >changes in the standard. Let fix it one way or another, but till >Geneva! >------------------------------------------------------------------------ >------------- >> >>4. H.450.2 Clause 10.6.1.1 >>This clause is talking about Call Transferring in case of GK Call >>Routed model and both Q.931 Signaling and H.245 protocol are "routed" >>by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >>Signaling is routed by the GK, but H.245 messages flow directly is >>legal and more efficient. It seems that the clause above doesn't cover >>this case. In order to provide a working solution for this case, an >>additional OPTIOANAL field "h245Address" should be added to >>Facility-UUIE message ... > >------------------------------------------------------------------------ >------------- >Three things on this: >Firstly, Pete, you are right about the "future study". Still this mode >is more efficient and we shouldn't cancel it without serious >considerations. In this case (of H.450.2) with this optional field we >could support it. Do we want to cancel the possibility of using this >mode without even studying it ? >Secondly, the facility message, described in H.450.2 section, may >contain Facility-UUIE as a part of it. Currently this Facility-UUIE is >empty, but it can be used and have a new h245Address field. >Thirdly, I will try to explain the relevant scenario using H.450.2 >terminology. Suppose, A and B are in the GK routed call, while H.245 >and UDP streams flow directly between them. All "transferring logic" is >performed by the GK on behalf of B. None of the mentioned messages >(specifically CONNECT message) reaches B. Still, when the call is >transferred from A to C, B has to receive (a new) H.245 address of C. >The proposed way to receive it, is by means of FACILITY message >containing Facility-UUIE. Pay attention that B, who doesn't perform the >"transferring logic" itself, upon arrival of the FACILITY message >containing a new H.245 address, has to close the old H.245 channel and >open a new one (towards C). >------------------------------------------------------------------------ >------------- > >(I am starting to enjoy it, but I am serious.) > >>>Thanks, >> >>Orit Levin >>RADVision Inc. E Mail: orit(a)radvision.com >>575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 >>Mahwah, NJ 07430 Fax: 201-529-3516 >> >

3 2

Re: Pete Cordell's FastStart issues
by Jim Toga 09 Dec '97

09 Dec '97

Pete, Thanks for you response. It looks like you have articulated some useful functionality in the ability to quickly switch media channels, but this is orthogonal to the FastStart sequence. I would be very interested in pursuing a light weight media switching in _all_ cases, independant of FastStart or any other control establishment that exists in H.323. I have tried to clarify and corrected some of your statements by referencing APC documents and presume that we are getting to the same 'wavelength'. Best Regards, jimt. > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk] > Sent: Monday, December 08, 1997 9:16 AM > Subject: RE: Pete Cordell's FastStart issues > > Jim et al., > > I'm glad we've got a discussion going on this. This seems to be a > really big issue that can have a major impact on the future of H.323. I > know we're all really busy, but come January we will be stuck with what > ever we decide, so I'm hoping that other people can jump in here to > thrash out the issues as much as possible. The more input, the better > the solution is likely to be. To be honest, it looks like H.323 is having a serious impact even without V2..... :-) > > I've put comments in below. From the comments presented though I don't > think we are on the same wavelength yet, so most of the comments are > related to the problem space rather than any solutions. I thought we had agreement. The functionality that you would like is the ability to break and re-make 'connections' in a lightweight manner. (which I still assume are media channels, unless you tell me otherwise...) > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] > >Sent: 07 December 1997 19:18 > >Subject: Re:Pete Cordell's FastStart issues > > > >Pete, (and others) > > > >Let me try and respond to your issues and hopefully we can resolve this > >in a relatively concise manner. Before we get started though I would like > >to make a couple of points clear: > > > >Recall that the "fast start" problem as stated previous to the Israel > >meeting and formalized in the contribution to that meeting, was the > >following. To provide a minimal round trip time connection sequence, > >for simple constrained calling scenarios. The requirement was to have > >minmal engineering impact to current shipping products and complete backward > >compatability. > I've looked through my notes and I can see any authoritative, exclusive > list of what the fast start should be expected to solve. I don't see > anything that said it should be restricted to "simple constrained > calling scenarios". There were verbal discussions before Israel, these were formalized in APC-1187 with the text: "Specifically with audio-only being the base system requirement, many current implementations are operating in this manner on the Internet. These environments provide many challenges to the implementers of these systems with regard to transmission delay, transport jitter, and overall reliability. Most if not all of these issues have been designed around by the developers, however there is one element that is inherent in the protocol and cannot be avoided; startup time. The number of RTT (round-trip-times) that occur in the normal startup of an H.323 call is typically 4 by the time the first media channel is open, assuming that both ends are truly asynchronous. (Setup-Connect, Cap Sets, M/S, OLC). On the Internet, this number of RTTs can lead to very long connect times, independent of the quality of the implementation. Users expectations (such as those using H.323 for Internet-telephony) may never be met in some situations. The solution to this, is to simply cut down on the number of RTTs - an optimal number would be 1. The idea is to provide a mechanism by which an H.323 terminal could call another terminal and operate in a �fast� mode (i.e. audio only) using only the Setup-Connect sequence. The called terminal would always have the option of �refusing� this �fast� mode and continuing in the standard manner." This same text was in APC-1306 at Sun River and was approved without changes. > > > >I have always been a proponent of Gatekeepers and the functionality, > >features, and services that they can provide. > > > >Everyone (including you), supported the final version of FastStart > >which came out SunRiver with the additions of bi-directional capabilities. > >With the presentation of your alternative approach there was never any clear > >motivation for developing the more complicated version other than you > >'didn't like' the current form. I'm happy to see you've presented a > >real issue to which you would like a solution. > > > >I would like codify my understanding of your issues and see if we can > >find a solution to them. I _think _you imply the need for a low overhead > >'mode switch' which really has nothing to do with FastStart, but let me see > >if I understand your points. > To me connection setup (i.e. user-to-user connection) is pretty much all > that H.323 is about. Once a connection is setup there is little more > for H.323 to do, other than tear-down. I'm still confused by what you mean by connection. By 'call startup' what is meant in the above APC's is the point at which the caller and callee can begin exchanging media. > > > > > >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote: > >[SNIP] > >> Each user has an account on the system. They can use > >>it as a single number by which to contact them by. As you move from > >office to home to mobile, you configure it using a web browser with > >>the number to contact you on. People trying to contact you dial a > >>single number and the platform forwards the call to the correct location. > >> It also allows people to leave voice messages on the system. > >>Additionally you can configure it to do things like try the office phone > >>first, then the mobile and if that doesn't work leave a message. This > >>sort of flexibility is not easily addressed by a directory. It > >>can also receive e-mails and faxes etc. > >> > >[SNIP] > > > >>This is admittedly not rocket science, and you've probably come across > >>services like this already. Our job is to move this to the IP world. > > > >Why can't you can accomplish this today (in R2) with the multiple alias > >registrations (that fact that you may use WEB front end is irrelevent)? > >The Gatekeeper then has his 'rotary switch' of locations to look through to > >find the current active location. This is much like (if not exactly) > >VocalTec's CMA architecture. > Your right, the configuration side of things is not the issue. > > > >>Product Impact > >>============== > >>To understand the impact of this on the protocol, let's look at the case > >>of using a search algorithm to look for a user and also returning a call > >>after interrogating the voice bank. > >> > > > >Tying user-network signalling to network-network signalling in the > >protocol is bad practice, limiting and cumbersome. > I agree, network-network signalling is for another day. However this > issue is very much in the user-network signalling area. The issues > remain even if only one gatekeeper is involved (which hopefully implies > that there is no network-network signalling). I still don't think we want to burden the endpoints with a 'search algorithm to look for a user'. The user-network signaling is contained in the ACF (or perhaps a GK routed Setup) anything more complicated seems a lot like network-network signalling. (Or at least for further study :-) ) > > > >>Let's assume the system is configured to contact my work number first > >>and them my mobile number. In this case the final connected endpoint is > >> not known until the CONNECT message is received. Hence the > >>capabilities of the endpoint you will be talking to are not known for > >>sure until you get CONNECT. > > > >I see this, and agree it is entirely true. It has no effect however on > >the the capabilities of the _calling_ party. They _are_ known, and there > >is no reason why the possibile capabilities should change. > Correct > > > >>This is not a problem with the basic call setup sequence as the H.245 is > >>not established until after CONNECT. > > > >This is not quite true. There has been the ability (since 3/96) to > >start H.245 at any point after the SETUP message is received. This required > >two things, which by the way would be required in all of these scenarios. > > > >The caller and callee has to be able to deal with H.245 and possibly > >media, 'early'. The caller has to place the H.245 port in the Setup message. > >(Alternatively the callee can place the H.245 port in the Call > >Proceeding/Alerting message) > True, but hopefully you'll agree with me that in this case the > gatekeeper could delete any H.245 addresses from messages other than > CONNECT and it would get the desired behaviour. As you point out, the Gatekeeper has full control. In fact it can enable or disable the FastConnect sequence as well. >This seems to be a pretty NULL operation as nobody seems to be sending H.245 addresses in > messages other than connect anyway. Exactly point the point I made below concerning the Facility message. Endpoint manufactures would like to have the option of a low impact, one roundtrip connect sequence. > > > >>However, with fast connect we want to start capability negotiation as > >>soon as possible, and are not able to wait until CONNECT. > > > >The Determined version of FastStart DOES do a full capability exchange > >before the CONNECT. (althought it does not provide for an iterative > >_negototiation_, as this defeats the Fast portion of FastStart). > I have problems with saying the FastStart shall be 1 round trip or bust. > The intent seems to have been that a minimum of round trips should be > used compatible with negotiation, security etc. If a particular case > requires an extra round trip, then that is the minimum number of round > trips that case can be set up in. That doesn't break fastStart. I > would say it's good because it has meant that we don't fall back to the > 6 1/2 round trips that we typically need. No, actually the original intent (see above) was to establish a one round trip method. The negotiation is poorly termed it really should be called 'capabilities exchange'. Both this, and security require no extra messages or round trips. > > > >>This also has the benefits that we can listen to announcements prior to > >>the CONNECT message (such as "The number you have dialled has > >>changed, but we are re-routing you anyway"). > > > >This is EXACTLY what FastStart provides as soon as the Setup is > >recieved, the recipient may start playing media back to the caller. The caller > >may be constrained from sending media to the callee until the Connect is > >received - just as it works in the circuit world. > I was trying to capture the issues here, not saying that the current > fast start doesn't meet any of them. Basically we have conflicting > requirements here 1) we want to establish media prior to CONNECT to > allow announcements, 2) we want to delay establishing media until after > CONNECT so that the gatekeeper can do some intelligent stuff. This is > what makes this topic so interesting!!!! Seems like you _have_ established the media stream back to the caller; it is just that you are switching the ultimate source of that media. In the case you describe, it seems like you want the protocol signalling to be aware of this - I'm not sure why. > > > >>However, if the system gives up ringing my work number and then tries > >>the mobile number, it has to present a new set of capabilities to the > >calling endpoint. > > > >That is true, and this can occur by simply sending another Call > >Proceeding message (or Alerting) with the new caps. There is no need however for > >the _caller_ change or otherwise resend its caps..... In other words the > >Gatekeeper will still be presenting the same set to the subsequent > >callees as it polls them. > You're right that the caller does not have to generate new caps. > However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint > breaks H.225, and so would not be backwards compatible. Why does it break H.225.0? FastStart will not be supported by Rev1 endpoints in any case which is why there is backward compatible signalling. > > > >>Now I'm in the mode of interrogating the voice messages that have been > >>left for me. My endpoint is connected to the sub-system that plays out > >>the recorded messages and it asks me if I want to return the > >>call. To do this the system needs to create an outgoing call, and > >>locally generate a ringing tone. When the remote party answers the two > >>endpoints need to be connected together. > > > >This is either some form of a transfer (from a protocol point of view) > >or shouldn't it be hidden from the endpoint in terms of signalling? > In a distributed world there is only so much that you can hide from an > endpoint. That's why this topic is so important. To roll out customer > friendly services the endpoints need to support some basic capabilities. > Hopefully this is worth endpoint vendors doing as useful services mean > that people can use there endpoints for more things. Thus the > technology is more likely to catch on, than if you are only likely to > get reasonable service from a call centre via good old POTS. It would seem to me that endpoint vendors would make a trade-off on what customers request for functionality vs the general industry support and ease of implementation of that functionality. I do know of one vendor :-) that is interested in making sure that rolling out of "customer friendly services" is possible, and for customers to utilize endpoints for more "things". > > > >>You may say that the FACILITY message could be used to do this. However, > >>the caller has state stored > >>in the platform/gatekeeper (such as where they are in the menus etc.) so > >>that when they finish this new call they can go back to interrogating their messages. > >>This would not be possible with the FACILITY approach. > > > >It would seem that exposing this bookkeeping/signalling would require a > >_large_ commitment on the part of all the endpoint manufacturers - > >wouldn't it be better to provide this in an 'invisible' way? Aside from the > >complexity/compatibiliy issues it provides for product differentiation. > I think you're agreeing with me that the FACILITY way is a bad way to go. > > > >> > >>WOW that's complicated!!! > >>========================= > >>At first sight this appears horrendous, but in actual fact it is quite > >>simple. All it requires is for the platform/gatekeeper to be able to > >break connections and re-establish > >>new connections when it wants to. > > > >AAHHH.... so this is what you wanted! This _does_ seem like a > >'transfer' type of thing, in any case it would appear to be independant of > >FastStart. > A setup is almost invariably part of transfer, so I don't see that you > can call them independent. Anyway, the report from Hertzliya says > support for supplementary services should be included in fast setup. Actually the meeting report said just the opposite. In APC-1249 (the meeting report) on page 8 it says "A. Supplementary services must consider fast cut-thru, and...." A Setup is invariably part of transfer, but only if that transfer envolves the _control channel_. It is not clear that you wanted this, I thought we were talking about media. During your sequence does the Gatekeeper 'get out of the way' when the final endpoint is found? Or for the duration of the call does the Gatekeeper act as a 'proxy' for the other endpoint ? (i.e. stay in the Gatekeeper routed model) > > > >I have to admit, I'm not sure what you mean by 'connection' though. Is > >this simply logical media channels, or is it a larger concept? > I'm really mean establishing some sort of media exchange between users > such as audio or video. OK, so OpenLogicalChannels, not establishing H.225.0 or H.245? > > > >[SNIP] > > > >> > >>So where's the problem > >>====================== > >>The problem is that I can not make use of the fast setup scheme with > >>these services, because it does not support the break and make > capability. > > > >This is _new_ functionality that was never listed as a requirement of > >FastStart, and I would argue that 'breaking and making connections' > >goes against the scope of the FastStart usefulness. > This is where I totally disagree. The list of fast start requirements > was never exclusive. We announced our requirements for fast start and > no body objected to them, and some even backed them up. If you had > objections you should have raised them at the time. > > > >>To do these services I need tofall back to H.245. If the > >>standard setup is not good enough for a basic point-to-point call then > >>it is not good enough for entities that introduce intelligence which in > >>fact have more stringent timing > >>requirements because the breaks and makes are more difficult to conceal > >under things like ringing. > > > >The 'standard setup' is no way "not good enough" for basic > >point-to-point operation. It simply as case that in certain well defined (resources > >and entities known) that optimizations can and should be made to operate in > >simple low delay environments. > > > >>Assuming that the reason for implementing the gatekeeper routed model is > >>to add these sorts of features, then really the gatekeeper routed model becomes a second class citizen. This > >>is a problem for us. > > > >The Gatekeeper should most definitely NOT be constrained from adding > >features and providing expanded services. The Gatekeeper routed model > >was specifically developed to hide this complexities from the endpoints, in > >fact the endpoint cannot even tell which mode it is running in other > >than a bit in the ACF. > > > >The Gatekeeper is no more or less a "second class citizen" with > >FastStart as with the 'standard' signaling. In fact I believe that it has even > >more control, because it may provide an asymmetrical connection on either > >side of itself forcing either the caller or callee into a particular mode of > >operation. > If the standard startup is good enough then we seem to be taking > elaborate measures to tune the efficiency of the "standard setup". In general, you can either have it 'fast' or you can have 'powerful and flexible'. I'm not implying at all that it should be an either/or situation. Why do we allow different media codecs? Some modes are better for one situation, some are better for others. > Either the standard setup is good enough or it isn't. If it is good > enough then we don't need fast start. I happen to think that it is not > good enough. Hence we need a solution that is good enough for the basic > call model and is also good enough for those of us that want to add > value. If we don't achieve this, then as far as I can see the > gatekeeper routed model can only become a second class citizen. I just don't understand this statement. The basis for being a 'second class citizen' seems to be that Gatekeepers don't have a special mode to swap media channels which no other entity has either. Again, this just seems to be completely orthonganl to FastStart. > > > >> > >>Where to go next > >>================ > >>To do what I need to do, I need a fast method for making and breaking > >>connections without first establishing the TCP connection, negotiating > >>caps, MSD, OLC, OLC ACK, > >>and then sending media. We could achieve this by adding a break command > >>to the FACILITY message and then having the ability to send new > >>fastCaps at any time to make a new connection. This seems a minimal > >>change from where we are at the moment and such a change would be fine > >>by me. > > > >Again I'm not clear on what you mean by 'connections', but assuming > >that you mean something like an audio channel (say 711-->723.1) than I think > >there are a number of fine options we can pursue. (for example H.245 > >has established a 're-open' command.) > > > >> > >>However, I know that Glen is interested in always running an MC, so he > >>would want to add extra features. Others will probably also want features > >>that have been carefully crafted > >>into H.245. As a result we are likely to get feature creep so that more > >and more H.245 functionality is put into H.225. > > > >I completely agree that it would be a very bad thing to re-invent H.245 within H.225.0. > > > >> I also have concerns about having two ways and two APIs (fast and slow) > >> for doing things. This explains my attempt to re-use as much of H.245 as possible. > > > >To pick a nit, we're not talking about API's; there is one way within > >the protocol to establish an H.245 connection. If you need these features, > >flexibility and control; this is what you should do. That being said > >there are two forms of Setup/Connect messages for those > >Endpoints/Gatekeepers/MCUs that would like to utilize them. > To pick more nits ( :-) ), we at some point have to build what we > propose. Therefore, we can not conceive of protocols in isolation of > how we will build them. If one protocol idea is easier to develop than > another then we should go with that one. So although the ITU is not > bothered with APIs, we as contributors, should be. > > Most stacks that I am aware of separate out the Q.931 part and the H.245 > part. At the moment the H.245 part knows about caps and the Q.931 part > does not. To put caps in Q.931 we need to put an API on the Q.931 part > that accepts caps. Therefore we really do have two APIs, which is an > issue. I can't comment on your development environment or platform, I only know it is not an issue in many of the currently shipping products. > > > >> > >>But let me reassure you I have no requirement to use H.245! I have a > >>requirement to solve the problem presented above. > > > >The problem is to 'break and make' connections with minimal > >overhead?..... > Yep > > > >> > >>A little history > >>================ > > > >[SNIP]. > The issues raised here are hopefully covered off elsewhere. > > > >> > >>To sum up > >>========= > >>To differentiate I want to add intelligence to my platform (effectively > >>a gatekeeper). If I can't use fast setup as part of this people will > >>either use the direct call model, > >>or use dumb gatekeepers. Basically the gatekeeper routed model will loose > >out. > > > >Nothing you have described so far is either helped or hindered by > >FastStart, this point is completely irrelevent. As I said above, > >Intel has always believed in the value of Gatekeepers to H.323 systems. I'm > >surprised that you didn't present a contribution to provide > >lightweight 'connection switching' in a general manner. > The point really is that it has not helped...... > > > >> > >>Hence I need fast setup to be useful for a gatekeeper adding > >>intelligence, which basically means being > >>able to quickly break and make connections. > > > >This is great! If this is what you require, lets come to quick > >agreement on this and move on. > > > >> > >>I have presented a solution that I believe meets these requirements. > >>But if there is another way of meeting my requirements then I would be > >only too happy to adopt it. > >> > > > >Here are my suggestions that I _think_ provide the functionality you > >desire: > I think it's important that we try to sort out the problem we are > solving first. If you feel we are on the same wavelength then we can > move on to the technical implementation, but I don't think we are quite > there yet. I hope this has helped. Besides, I would also like more > time to think about what you have proposed. > > > > > [SNIPPED, but not forgotten] > > > >Does this solve your issues? > > This is a good start and I'm confident that in a few rounds we can get > there. Thanks for the time you've put into this Jim. You may not thank > me now, but I'm sure that in a few years you (or your company) will > thank me for bringing this all up!!!! (well say 10 years. Or not more > than 20 years. Well not much more than 20 years....) Let's keep slogging away, You know I'll always thank you Pete... :-) I'm hoping that I have picked the issue that you would like to solve and that one of the previous solutions works for you. > > > >Best Regards, > >jimt. > > > > Pete > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Re: Pete Cordell's FastStart issues
by Tom Taylor 09 Dec '97

09 Dec '97

Thanks, Toby. I didn't reealize this discussion was going on, and it looks interesting. Tom Taylor >-----Original Message----- >From: Toby Nixon [SMTP:tnixon@MICROSOFT.COM] >Sent: Monday, December 08, 1997 3:23 PM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Pete Cordell's FastStart issues > >Might I suggest that this discussion be broadened to include the ITU-SG16 >reflector instead of sending a long list of recipients each time? > >[Taylor, Tom (P.T.)] [snip]

1 0

Re: Pete Cordell's FastStart issues
by Toby Nixon 08 Dec '97

08 Dec '97

Might I suggest that this discussion be broadened to include the ITU-SG16 reflector instead of sending a long list of recipients each time? > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk] > Sent: Monday, December 08, 1997 9:16 AM > To: 'pete.cordell(a)bt-sys.bt.co.uk'; 'Narjala_Bhasker(a)ccm.jf.intel.com'; > 'Vineet_Kumar(a)ccm.jf.intel.com'; 'amir(a)radvision.rad.co.il'; > 'gthom(a)DELTA-INFO.COM'; 'lindbergh(a)pictel.com'; 'reid(a)pictel.com'; > 'Scott_Petrack(a)VOCALTEC.COM'; 'okubo(a)gctech.co.jp'; Toby Nixon; Steve > Liffick; 'karl.klaghofer(a)MCH.PN.SIEMENS.DE'; 'amotz(a)radvision.rad.co.il'; > 'sebes(a)PNSTA1.ZFE.SIEMENS.DE'; 'dskran(a)ascend.com'; > 'nstarkey(a)databeam.com'; 'Robert.Callaghan(a)SIEMENSCOM.COM'; > 'gkajos(a)videoserver.com'; 'ggf(a)lucent.com'; 'jeff(a)pictel.com'; > 'john.boucher(a)bt-sys.bt.co.uk'; 'gkisor(a)ideal.jf.intel.com'; > 'reinhard.scholl(a)oen.siemens.de'; 'ofer(a)radvision.rad.co.il'; > 'nilsson_m_e(a)bt-web.bt.co.uk'; 'helmut.schink(a)oen.siemens.de'; > 'roni_e(a)accord.co.il'; 'gfargo(a)intecom.com'; 'adfranklin(a)lucent.com'; 'Jim > Toga' > Subject: RE: Pete Cordell's FastStart issues > > Jim et al., > > I'm glad we've got a discussion going on this. This seems to be a > really big issue that can have a major impact on the future of H.323. I > know we're all really busy, but come January we will be stuck with what > ever we decide, so I'm hoping that other people can jump in here to > thrash out the issues as much as possible. The more input, the better > the solution is likely to be. > > I've put comments in below. From the comments presented though I don't > think we are on the same wavelength yet, so most of the comments are > related to the problem space rather than any solutions. > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] > >Sent: 07 December 1997 19:18 > >To: pete.cordell(a)bt-sys.bt.co.uk; Narjala_Bhasker(a)ccm.jf.intel.com; > >Vineet_Kumar(a)ccm.jf.intel.com; amir(a)radvision.rad.co.il; > >gthom(a)DELTA-INFO.COM; lindbergh(a)pictel.com; reid(a)pictel.com; > >Scott_Petrack(a)VOCALTEC.COM; okubo(a)gctech.co.jp; tnixon(a)MICROSOFT.COM; > >stevel(a)MICROSOFT.COM; karl.klaghofer(a)MCH.PN.SIEMENS.DE; > >amotz(a)radvision.rad.co.il; sebes(a)PNSTA1.ZFE.SIEMENS.DE; > >dskran(a)ascend.com; nstarkey(a)databeam.com; > >Robert.Callaghan(a)SIEMENSCOM.COM; gkajos(a)videoserver.com; > >ggf(a)lucent.com; jeff(a)pictel.com; john.boucher(a)bt-sys.bt.co.uk; > >gkisor(a)ideal.jf.intel.com; reinhard.scholl(a)oen.siemens.de; > >ofer(a)radvision.rad.co.il; nilsson_m_e(a)bt-web.bt.co.uk; > >helmut.schink(a)oen.siemens.de; roni_e(a)accord.co.il; gfargo(a)intecom.com; > >adfranklin(a)lucent.com > >Cc: jtoga(a)ideal.jf.intel.com > >Subject: Re:Pete Cordell's FastStart issues > > > >Pete, (and others) > > > >Let me try and respond to your issues and hopefully we can resolve this > >in > >a relatively concise manner. Before we get started though I would like > >to > >make a couple of points clear: > > > >Recall that the "fast start" problem as stated previous to the Israel > >meeting and formalized in the contribution to that meeting, was the > >following. To provide a minimal round trip time connection sequence, > >for > >simple constrained calling scenarios. The requirement was to have > >minmal > >engineering impact to current shipping products and complete backward > >compatability. > I've looked through my notes and I can see any authoritative, exclusive > list of what the fast start should be expected to solve. I don't see > anything that said it should be restricted to "simple constrained > calling scenarios". > > > >I have always been a proponent of Gatekeepers and the functionality, > >features, and services that they can provide. > > > >Everyone (including you), supported the final version of FastStart > >which > >came out SunRiver with the additions of bi-directional capabilities. > >With > >the presentation of your alternative approach there was never any clear > >motivation for developing the more complicated version other than you > >'didn't like' the current form. I'm happy to see you've presented a > >real > >issue to which you would like a solution. > > > >I would like codify my understanding of your issues and see if we can > >find > >a solution to them. I _think _you imply the need for a low overhead > >'mode > >switch' which really has nothing to do with FastStart, but let me see > >if I > >understand your points. > To me connection setup (i.e. user-to-user connection) is pretty much all > that H.323 is about. Once a connection is setup there is little more > for H.323 to do, other than tear-down. > > > > > >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote: > >[SNIP] > >> Each user has an account on the system. They can use > >>it as a single number by which to contact them by. As you move from > >office to home to mobile, > >>you configure it using a web browser with > >>the number to contact you on. People trying to contact you dial a > >>single number and the platform forwards the call to the correct > location. > >> It also allows people to leave voice messages on the system. > >>Additionally you can configure it to do things like try the office phone > >>first, then the mobile and if that doesn't work leave a message. This > >>sort > >> of flexibility is not easily addressed by a directory. It > >>can also receive e-mails and faxes etc. > >> > >[SNIP] > > > >>This is admittedly not rocket science, and you've probably come across > >>services like this already. Our job is to move this to the IP world. > > > >Why can't you can accomplish this today (in R2) with the multiple alias > >registrations (that fact that you may use WEB front end is irrelevent)? > >The > >Gatekeeper then has his 'rotary switch' of locations to look through to > >find the current active location. This is much like (if not exactly) > >VocalTec's CMA architecture. > Your right, the configuration side of things is not the issue. > > > >>Product Impact > >>============== > >>To understand the impact of this on the protocol, let's look at the case > >>of using a search algorithm to look for a user and also returning a call > >>after interrogating the voice bank. > >> > > > >Tying user-network signalling to network-network signalling in the > >protocol > >is bad practice, limiting and cumbersome. > I agree, network-network signalling is for another day. However this > issue is very much in the user-network signalling area. The issues > remain even if only one gatekeeper is involved (which hopefully implies > that there is no network-network signalling). > > > >>Let's assume the system is configured to contact my work number first > >>and them my mobile number. In this case the final connected endpoint is > > >> not known until the CONNECT message is received. Hence the > >>capabilities of the endpoint you will be talking to are not known for > >>sure until you get CONNECT. > > > >I see this, and agree it is entirely true. It has no effect however on > >the > >the capabilities of the _calling_ party. They _are_ known, and there > >is no > >reason why the possibile capabilities should change. > Correct > > > >>This is not a problem with the basic call setup sequence as the H.245 is > > >>not established until after CONNECT. > > > >This is not quite true. There has been the ability (since 3/96) to > >start > >H.245 at any point after the SETUP message is received. This required > >two > >things, which by the way would be required in all of these scenarios. > > > >The caller and callee has to be able to deal with H.245 and possibly > >media, > >'early'. > >The caller has to place the H.245 port in the Setup message. > >(Alternatively the callee can place the H.245 port in the Call > >Proceeding/Alerting message) > True, but hopefully you'll agree with me that in this case the > gatekeeper could delete any H.245 addresses from messages other than > CONNECT and it would get the desired behaviour. This seems to be a > pretty NULL operation as nobody seems to be sending H.245 addresses in > messages other than connect anyway. > > > >>However, with fast connect we want to start capability negotiation as > >>soon as possible, and are not able to wait until CONNECT. > > > >The Determined version of FastStart DOES do a full capability exchange > >before the CONNECT. (althought it does not provide for an iterative > >_negototiation_, as this defeats the Fast portion of FastStart). > I have problems with saying the FastStart shall be 1 round trip or bust. > The intent seems to have been that a minimum of round trips should be > used compatible with negotiation, security etc. If a particular case > requires an extra round trip, then that is the minimum number of round > trips that case can be set up in. That doesn't break fastStart. I > would say it's good because it has meant that we don't fall back to the > 6 1/2 round trips that we typically need. > > > >>This also has the benefits that we can listen to announcements prior to > >the CONNECT >message (such as "The > > >number you have dialled has > changed, but we are re-routing you > >anyway"). > > > >This is EXACTLY what FastStart provides as soon as the Setup is > >recieved, > >the recipient may start playing media back to the caller. The caller > >may > >be constrained from sending media to the callee until the Connect is > >received - just as it works in the circuit world. > I was trying to capture the issues here, not saying that the current > fast start doesn't meet any of them. Basically we have conflicting > requirements here 1) we want to establish media prior to CONNECT to > allow announcements, 2) we want to delay establishing media until after > CONNECT so that the gatekeeper can do some intelligent stuff. This is > what makes this topic so interesting!!!! > > > >>However, if the system gives up ringing my work number and then tries > >>the mobile number, it has to present a new set of capabilities to the > >calling endpoint. > > > >That is true, and this can occur by simply sending another Call > >Proceeding > >message (or Alerting) with the new caps. There is no need however for > >the > >_caller_ change or otherwise resend its caps..... In other words the > >Gatekeeper will still be presenting the same set to the subsequent > >callees > >as it polls them. > You're right that the caller does not have to generate new caps. > However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint > breaks H.225, and so would not be backwards compatible. > > > > > >>Now I'm in the mode of interrogating the voice messages that have been > >>left for me. My endpoint is connected to the sub-system that plays out > >the recorded > >>messages and it asks me if I want to return the > >>call. To do this the system needs to create an outgoing call, and > >>locally generate a ringing tone. When the remote party answers the two > >endpoints need > >>to be connected together. > > > >This is either some form of a transfer (from a protocol point of view) > >or > >shouldn't it be hidden from the endpoint in terms of signalling? > In a distributed world there is only so much that you can hide from an > endpoint. That's why this topic is so important. To roll out customer > friendly services the endpoints need to support some basic capabilities. > Hopefully this is worth endpoint vendors doing as useful services mean > that people can use there endpoints for more things. Thus the > technology is more likely to catch on, than if you are only likely to > get reasonable service from a call centre via good old POTS. > > > >>You may say that the FACILITY message could be used to do this. > However, > >the caller has state stored > >>in the platform/gatekeeper (such as where they are in the menus etc.) so > >that when they finish this new > >>call they can go back to interrogating their messages. This would not > be > >possible with the > >>FACILITY approach. > > > >It would seem that exposing this bookkeeping/signalling would require a > >_large_ commitment on the part of all the endpoint manufacturers - > >wouldn't > >it be better to provide this in an 'invisible' way? Aside from the > >complexity/compatibiliy issues it provides for product differentiation. > I think you're agreeing with me that the FACILITY way is a bad way to > go. > > > >> > >>WOW that's complicated!!! > >>========================= > >>At first sight this appears horrendous, but in actual fact it is quite > >>simple. All it requires is for the platform/gatekeeper to be able to > >break connections and re-establish > >>new connections when it wants to. > > > >AAHHH.... so this is what you wanted! This _does_ seem like a > >'transfer' > >type of thing, in any case it would appear to be independant of > >FastStart. > A setup is almost invariably part of transfer, so I don't see that you > can call them independent. Anyway, the report from Hertzliya says > support for supplementary services should be included in fast setup. > > > >I have to admit, I'm not sure what you mean by 'connection' though. Is > >this simply logical media channels, or is it a larger concept? > I'm really mean establishing some sort of media exchange between users > such as audio or video. > > > >[SNIP] > > > >> > >>So where's the problem > >>====================== > >>The problem is that I can not make use of the fast setup scheme with > >>these services, because it does not support the break and make > capability. > > > >This is _new_ functionality that was never listed as a requirement of > >FastStart, and I would argue that 'breaking and making connections' > >goes > >against the scope of the FastStart usefulness. > This is where I totally disagree. The list of fast start requirements > was never exclusive. We announced our requirements for fast start and > no body objected to them, and some even backed them up. If you had > objections you should have raised them at the time. > > > >>To do these services I need tofall back to H.245. If the > >>standard setup is not good enough for a basic point-to-point call then > >>it is not good enough for entities that introduce intelligence which in > >fact have more stringent timing > >>requirements because the breaks and makes are more difficult to conceal > >under things like ringing. > > > >The 'standard setup' is no way "not good enough" for basic > >point-to-point > >operation. It simply as case that in certain well defined (resources > >and > >entities known) that optimizations can and should be made to operate in > >simple low delay environments. > > > >>Assuming that the reason for implementing the gatekeeper routed model is > >to add these sorts of features, then > >>really the gatekeeper routed model becomes a second class citizen. This > >is a problem for us. > > > >The Gatekeeper should most definitely NOT be constrained from adding > >features and providing expanded services. The Gatekeeper routed model > >was > >specifically developed to hide this complexities from the endpoints, in > >fact the endpoint cannot even tell which mode it is running in other > >than a > >bit in the ACF. > > > >The Gatekeeper is no more or less a "second class citizen" with > >FastStart > >as with the 'standard' signaling. In fact I believe that it has even > >more > >control, because it may provide an asymmetrical connection on either > >side > >of itself > >forcing either the caller or callee into a particular mode of > >operation. > If the standard startup is good enough then we seem to be taking > elaborate measures to tune the efficiency of the "standard setup". > Either the standard setup is good enough or it isn't. If it is good > enough then we don't need fast start. I happen to think that it is not > good enough. Hence we need a solution that is good enough for the basic > call model and is also good enough for those of us that want to add > value. If we don't achieve this, then as far as I can see the > gatekeeper routed model can only become a second class citizen. > > > >> > >>Where to go next > >>================ > >>To do what I need to do, I need a fast method for making and breaking > >>connections without first establishing the TCP connection, negotiating > >caps, MSD, OLC, OLC ACK, > >>and then sending media. We could achieve this by adding a break command > >to the FACILITY message and >then having the ability to send new > >fastCaps > >at any time to make a new connection. This seems a minimal > >>change from where we are at the moment and such a change would be fine > by > >me. > > > >Again I'm not clear on what you mean by 'connections', but assuming > >that > >you mean something like an audio channel (say 711-->723.1) than I think > >there are a number of fine options we can pursue. (for example H.245 > >has > >established a 're-open' command.) > > > >> > >>However, I know that Glen is interested in always running an MC, so he > >>would want to add extra features. Others will probably also want > features > >that have been carefully crafted > >>into H.245. As a result we are likely to get feature creep so that more > >and more H.245 functionality is > >>put into H.225. > > > >I completely agree that it would be a very bad thing to re-invent H.245 > >within H.225.0. > > > >> I also have concerns about having two ways and two APIs (fast and slow) > >for doing > >>things. This explains my attempt to re-use as much of H.245 as > possible. > > > >To pick a nit, we're not talking about API's; there is one way within > >the > >protocol to establish an H.245 connection. If you need these features, > >flexibility and control; this is what you should do. That being said > >there > >are two forms of Setup/Connect messages for those > >Endpoints/Gatekeepers/MCUs that would like to utilize them. > To pick more nits ( :-) ), we at some point have to build what we > propose. Therefore, we can not conceive of protocols in isolation of > how we will build them. If one protocol idea is easier to develop than > another then we should go with that one. So although the ITU is not > bothered with APIs, we as contributors, should be. > > Most stacks that I am aware of separate out the Q.931 part and the H.245 > part. At the moment the H.245 part knows about caps and the Q.931 part > does not. To put caps in Q.931 we need to put an API on the Q.931 part > that accepts caps. Therefore we really do have two APIs, which is an > issue. > > > >> > >>But let me reassure you I have no requirement to use H.245! I have a > >>requirement to solve the problem presented above. > > > >The problem is to 'break and make' connections with minimal > >overhead?..... > Yep > > > >> > >>A little history > >>================ > > > >[SNIP]. > The issues raised here are hopefully covered off elsewhere. > > > >> > >>To sum up > >>========= > >>To differentiate I want to add intelligence to my platform (effectively > >>a gatekeeper). If I can't use fast setup as part of this people will > >either use the direct call model, > >>or use dumb gatekeepers. Basically the gatekeeper routed model will > loose > >out. > > > >Nothing you have described so far is either helped or hindered by > >FastStart, this point is completely irrelevent. As I said above, > >Intel > >has always believed in the value of Gatekeepers to H.323 systems. I'm > >surprised that you didn't present a contribution to provide > >lightweight > >'connection switching' in a general manner. > The point really is that it has not helped...... > > > >> > >>Hence I need fast setup to be useful for a gatekeeper adding > intelligence, > >which basically means being > >>able to quickly break and make connections. > > > >This is great! If this is what you require, lets come to quick > >agreement on > >this and move on. > > > >> > >>I have presented a solution that I believe meets these requirements. > >>But if there is another way of meeting my requirements then I would be > >only too happy to adopt it. > >> > > > >Here are my suggestions that I _think_ provide the functionality you > >desire: > I think it's important that we try to sort out the problem we are > solving first. If you feel we are on the same wavelength then we can > move on to the technical implementation, but I don't think we are quite > there yet. I hope this has helped. Besides, I would also like more > time to think about what you have proposed. > > > > > [SNIPPED, but not forgotten] > > > >Does this solve your issues? > > This is a good start and I'm confident that in a few rounds we can get > there. Thanks for the time you've put into this Jim. You may not thank > me now, but I'm sure that in a few years you (or your company) will > thank me for bringing this all up!!!! (well say 10 years. Or not more > than 20 years. Well not much more than 20 years....) > > > >Best Regards, > >jimt. > > > > Pete > > > >************************************************************************ > >* > >*** +1-503-264-8816(voice) +1-503-264-3485(fax) > >*** > >*** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. > >*** > >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** > >************************************************************************ > >* > >

1 0

Re: Limitation of nonStandardData
by Pete Cordell 05 Dec '97

05 Dec '97

The reason for my gymnastics is to give transparency to implementations that already use nonStandardData and are already out there. A gatekeeper that sees previousNonStandard (I've changed the name to overWritten below in an attempt to increase the clarity) when it goes to remove its nonStandard part knows that an earlier gatekeeper in the chain overwrote nonStandardData that wasn't in this form and so can restore it as it was. This allows endpoints that are out there and only understand the data in the form that it presents it in can make use of it. >From a code impact point of view I see no difference between saying the OCTET STRING is SEQUENCE OF NonStandardParameter, or SEQUENCE { overWritten NonStandardParameter OPTIONAL, extra SEQUENCE OF NonStandardParameter } If you support the OID you have to write code either way. However, if nobody is using nonStandardData in the H.225 PDUs yet then we are trying to solve a problem that doesn't exist. So the question is: IS ANYBODY OUT THERE USING NONSTANDARDDATA AT THE MOMENT??? If not Jim's solution is fine. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >Sent: 05 December 1997 11:31 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >I rather thought that Jim's original solution, which is that we agree >to >get an OID which means "the OCTET STRING in the data part is actually a >SEQUENCE OF NonStandardParameter" was simple and clean and totally >compatible. (I don't really care whether it's SEQUENCE or SET). > >Is it possible just to write into the H.225/H.245 standards some OID >which >is actually within the tree of each standard and then add a single >sentence >to the standard which says something like "if the OID is xxxxxx then >the >data contains a sequence of NonStandardParameter." That's all. There is >no >compatibility problem, no one has to change code, that's all. If you >don't >need this OID then you don't use it. It doesn't need to change a line >of >anyone's code. Current implementations which don't recognize or send >this >OID work exactly as before. > >I would like to do this both in H.225 and H.245. In each case where the >nonStandardData is not now a sequence, I may in the future want to pass >some parameters through someone else's stack or through a cloud of >gatekeepers. All this discussion about "I can think of a case where it >won't work" are beside the point. The point is that I can think of >situations where it will work, and right now I have no choice but to >come >to private agreements on what the OID will be. *This* is a pain, as >well as >making it very difficult to work with more than one other person. An >agreement on a single OID will certainly improve useability and >interoperability. > >I thought that it's much too late to muck about with the actual >standards. >Quite frankly, I am likely to object to the ASN.1 gymnastics suggested >in >other letters, because this is real new code and new state suggested in >December when the thing is going to Decision in January! The simple >suggestion that we add an OID to the tree of H.225 and H.245 surely >solves >the problem in a way which is just an "editorial change". And if it's >too >late even for this, then let's do nothing now and put it into VoIP or >the >implementor's guide. > >Sorry if this note sounds rushed -- I am busy preparing for a difficult >IETF. > >Scott >

2 1

WP2 schedule
by Sakae Okubo 05 Dec '97

05 Dec '97

Dear Q.12-14 experts, Mr. Tosco's revised work plan for the coming WP2/16 meeting in Jan-Feb 1998 has been placed at the GCL ftp site: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/wp2_sche.doc There have been changes in Q.1 and Q.2 related parts. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Liaison Statement from MPEG to ITU-T SG 16 (SC 29 N 2312)
by Sakae Okubo 05 Dec '97

05 Dec '97

Dear Q.12-14/16 experts, Please be advised that SG16 has received MPEG liaison regarding DMIF. The following two files have been placed at the GCL ftp site /9801_Gen directory: SC 29 N 2312: ==> 29n2313.zip Liaison Statement from SC 29/WG 11 to ITU-T SG 16 on Cooperation on DMIF with ITU-T Rec. H.310 and H.323 [SC 29/WG 11 N 1946] with SC 29 N 2296 (as attachment): ==> 29n2296.zip ISO/IEC CD 14496-6: Information technology -- Very-low bitrate audio-visual coding -- Part 6: DSM-CC Multimedia Integration Framework (DMIF) [SC 29/WG 11 N 1906] Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Re: Limitation of nonStandardData
by Scott Petrack 05 Dec '97

05 Dec '97

I rather thought that Jim's original solution, which is that we agree to get an OID which means "the OCTET STRING in the data part is actually a SEQUENCE OF NonStandardParameter" was simple and clean and totally compatible. (I don't really care whether it's SEQUENCE or SET). Is it possible just to write into the H.225/H.245 standards some OID which is actually within the tree of each standard and then add a single sentence to the standard which says something like "if the OID is xxxxxx then the data contains a sequence of NonStandardParameter." That's all. There is no compatibility problem, no one has to change code, that's all. If you don't need this OID then you don't use it. It doesn't need to change a line of anyone's code. Current implementations which don't recognize or send this OID work exactly as before. I would like to do this both in H.225 and H.245. In each case where the nonStandardData is not now a sequence, I may in the future want to pass some parameters through someone else's stack or through a cloud of gatekeepers. All this discussion about "I can think of a case where it won't work" are beside the point. The point is that I can think of situations where it will work, and right now I have no choice but to come to private agreements on what the OID will be. *This* is a pain, as well as making it very difficult to work with more than one other person. An agreement on a single OID will certainly improve useability and interoperability. I thought that it's much too late to muck about with the actual standards. Quite frankly, I am likely to object to the ASN.1 gymnastics suggested in other letters, because this is real new code and new state suggested in December when the thing is going to Decision in January! The simple suggestion that we add an OID to the tree of H.225 and H.245 surely solves the problem in a way which is just an "editorial change". And if it's too late even for this, then let's do nothing now and put it into VoIP or the implementor's guide. Sorry if this note sounds rushed -- I am busy preparing for a difficult IETF. Scott

1 0

Re: Limitation of nonStandardData
by Bancroft Scott 05 Dec '97

05 Dec '97

On Thu, 4 Dec 1997, Paul Long wrote: > Paul Long wrote: > > > 4. As I understand it, for some strange reason, because the order of the > > > members of a SET OF is intended to be un-important the compiler takes it > > > upon itself to sort the values entered into some form of order!!! This > > > seems a waste of time and is a step best avoided by using SEQUENCE OF. > > > > I've never heard of this before. I'll check with Bancroft. Sounds like a > > bug in the OSS compiler, which by the way we don't use for reasons like > > this. > > [Bancroft's response follows. Apparently there is no reason _not_ to use > SET OF, because H.245, and H.225.0, and presumably H.450 use BASIC PER, > not CANONICAL PER, so there is no sorting.] > > This is true in the case of DER, which mandates this behavior. DER > encoders does not take it upon themselves to do this; it is required in > order to produce a valid DER encoding. This is also true in the case of > CER and the canonical variants of PER. It is not true for the > non-canonical variants of PER or for BER. > > As far as the OSS ASN.1 Tools go, DER is supported, so here SET OF's are > sorted as required. The OSS ASN.1 Tools at this time does not support > the canonical variants of PER, so no such sorting occurs for PER. Since > all the sorting algorithms are in place for DER, it is easy to provide > canonical PER support if it is required. I rarely recommend use of SET OF, for I can never tell when an existing standard is going to be used in the future for the base of another standard that happens to use DER, CER or canonical PER. Sticking to a semantically pure choice (i.e., SET OF) at this point can thus later result in either redefinition of the standard you are creating or in the future standard taking the CPU hit. On the other hand, if one is creating a standard that they *know* makes sense only using DER, CER or canonical PER (e.g., X.509), then a SET OF is actually a good thing for types whose values for some reason should be sorted in ascending order. In these cases SET OF is a good idea because based on the toolkit you are using the sort will be performed for you without your having to write added code. What I say here also applies to SET, which requires no sort of any kind in PER, but which can have unnecessary CPU and coding overhead for DER encoders which are required to sort it, and for BER decoders which have unnecessary CPU and coding overhead because the SET components can appear in any order. Most folks don't think that their ASN.1 specs will see life beyond their immediate application, but in practice the more successfully specs get used over and over again, often in ways that the authors never imagined. To allow such reuse is the reason I don't suggest use of SET, ever, and of SET OF only after serious thought. -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636

1 0

Re: Limitation of nonStandardData
by Pete Cordell 05 Dec '97

05 Dec '97

Jim, Scott, Douglas, Paul,..... To answer Paul's question about the need for the change first: We are mainly interested in gatekeepers. We have a need to ship nonStandard information between cooperating gatekeepers, particularly in the SETUP message. However, endpoints may also wish to ship their own nonStandard information which the gatekeeper doesn't want to stamp on (because I'm a nice guy!). Hence we both have a need to use a field that is only intended to carry one value. This helps identify a suitable syntax for the data that goes into the data part of nonStandard data, as I believe we need to cater for both the nested form (for backwards compatibility) and multiple pieces of nonStandard data without any particular order. To do this, I propose that the piece of ASN.1 put in the data part of nonStandardParameter should be: ExtendedNonStandardData ::= SEQUENCE { previousNonStandard NonStandardParameter OPTIONAL, extraNonStandard SEQUENCE OF NonStandardParameter, ... } This would be used as follows: A V1 endpoint could put its own piece of nonStandardData into the existing nonStandard field. When a gatekeeper (or something else) received it, it would take the data from the existing nonStandard field and put it in the previousNonStandard field of the above SEQUENCE. It would then add whatever nonStandard stuff it needed to the extraNonStandard bit. It would put the combined nonStandard data in the data part of the nonStandardParameter and give it the tag that we decide on. On the other side a gatekeeper could see that the extraNonStandard related to it, and remove parts the parts that it needed to. If all that was left was the previousNonStandard part, then it would use this to recover what was the original format of the nonStandard message. This allows endpoints to send nonStandardData transparently, but also allows gatekeepers to get in on the act. As far as how this is captured in the standard, this seems a fairly important feature for H.225. I think we should include this as a separate root in the H.225 ASN.1 and give a fairly official OBJECT IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which shouldn't clash with anything in the context that we are using it). I've used an unconstrained SEQUENCE OF for the following reasons: 1. No other SEQUENCE OFs are bounded within H.225. 2. Size constraints on SEQUENCE OF are not always that useful (especially in the case of H.245!) 3. We have no other SET OFs in H.225 4. As I understand it, for some strange reason, because the order of the members of a SET OF is intended to be un-important the compiler takes it upon itself to sort the values entered into some form of order!!! This seems a waste of time and is a step best avoided by using SEQUENCE OF. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Paul Long[SMTP:plong@SMITHMICRO.COM] >Sent: 02 December 1997 21:05 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Scott Petrack wrote: >> This problem has bothered me for a long time. I considered many times >> introducing into the VoIP Forum an OID which would be used precisely as Jim >> suggests, so that the entire industry could signal a SEQUENCE of >> NonStandardParameter. > >So do you mean something like this?: > > NonStandardParameter ::=SEQUENCE > { > nonStandardIdentifier NonStandardIdentifier, -- e.g., VoIP OID > data OCTET STRING > } > >where data contains the following: > > SET SIZE (1..256) OF NonStandardParameter > >BTW, I believe that it should be a SET OF and not a SEQUENCE OF, >because >SEQUENCE OF implies that the order is important, and I don't think that >is the intent here. Or is it? > >One way to handle this for _future_ syntax is to define a type that is >itself a set of NonStandardParameters, as in: > > NonStandardParameters ::=SEQUENCE > { > nonStandardParameters SET SIZE (1..256) OF NonStandardParameter > } > >> One example of why this is necessary is so that when someone else uses our >> stack we can both pass non-standard parameters. > >Just to play devil's advocate, can you give an example of a specific >need for this? A quick review of H.245 didn't turn up very many >situations where aggregation isn't handled already at a higher level or >where it just doesn't make sense in the first place. > >Here is an example of where iteration is expressed at a higher level. >The capability table contains multiple capabilities, so there is no >need >for a single capability containing multiple NonStandardParameters--just >add more nonStandard capabilities. Case in point: it makes no sense, >IMO, for UserInputCapability to have a nonStandard CHOICE of multiple >NonStandardParameters, when multiple nonStandard UserInputCapabilities >would have served just as well. I agree with Dykstra--_I don't like >more >than one way of doing the same thing._ > >An example of where multiple NonStandardParameters may not make sense >in >the first place is in the NonStandardMessage type. Is there ever a need >to combine several NonStandardParameters in the same RequestMessage, >for >example? IOW, these uses are atomic. > >-- >Paul Long___________________________http://www.cmpu.net/public/plong >Smith Micro Software, Inc.__________http://www.smithmicro.com/ >

3 3

Re: Limitation of nonStandardData
by Pete Cordell 04 Dec '97

04 Dec '97

Douglas, I couldn't have said it better... As far as constraints and SETs etc.... Paul, It's funny you mentioned 32MB because that's exactly how big an H.245 structure came out when we compiled it! Perhaps we did something wrong, but now we have gone to linked lists and its all hunky dory. My feeling is that if you use the fixed size constraints you are guaranteed to waste memory in systems that can't afford to waste it. What you need is a size constraint for the entire decoded message. Unfortunately ASN.1 does not give you such a feature. Woops, I have to take back what I said about the encoding of SET OF. It came from my hazy memory of the following paragraph from X.691: 21 Encoding the set-of type 21.1 For CANONICAL-PER the encoding of the component values of the set-of type shall appear in ascending order, the component encodings being compared as bit strings padded with as many as seven 0 bits to an octet boundary. NOTE - Any pad bits added to achieve octet alignment for the sort do not appear in the actual encoding. 21.2 For BASIC-PER the set-of shall be encoded as if it had been declared a sequence-of type. However, we are using the BASIC for so there shouldn't be a problem. For what it's worth, I agree that ERROR propagation is not a good thing, but, based on the premise that exceptional cases introduce bugs, SUB-OPTIMALITY propagation is not always a bad thing if it leads to consistency!!! Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >Sent: 04 December 1997 01:22 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Paul, > >There seems to be a mismatch in the understanding here and I'm not sure >that it isn't me. So I'll give my version the understanding and hope to >be >corrected where I'm wrong. (BTW, I don't understand what the '...' in >the >ASN.1 does and why it's in the middle of the H.323 V2 stuff.) > >At 13:25 3/12/97 -0800, Paul Long wrote: >>Pete Cordell wrote: >>> We are mainly interested in gatekeepers. We have a need to ship >>> nonStandard information between cooperating gatekeepers, particularly in >>> the SETUP message. >> >>Okay, I see that H.225.0 apparently wasn't engineered for multiple >>nonStandardParameters, whereas H.245 at least originally was, but at a >>higher level, not merely a SET OF NonStandardParameters. I agree that >>this is a problem in H.225.0, but I don't think there is a problem with >>H.245, unless someone can give me specific examples. >> > >The problem tends to arise in a channel where there are multiple nodes. >This could be true of RAS if there is a hierarchy of gatekeepers. It is >true of of the Call Signalling Channel and the H.245 Control Channel >when >going via one or more gatekeepers, proxies or other devices. > >An obvious problem arises in the following situation. Two endpoints >require >a NonStandardParameter in the Q.931 SETUP message so that they can >cooperative complete a connection. Two intermediate (to the endpoints) >and >cooperative gatekeepers require to add a NonStandardParameter for their >participation in the SETUP process. Two intermediate (to the >gatekeepers) >and cooperative proxies require to add a NonStandardParameter for their >own >use. The problem arises when the intermediaries throw away the >NonStandardParameter already in the message and substitute their own >because the syntax only allows one NonStandardParameter. > >I don't understand how H.245 intrinsically solves this problem for, >say, >OpenLogicalChannel. > >>> To do this, I propose that the piece of ASN.1 put in the data part of >>> nonStandardParameter should be: >>> >>> ExtendedNonStandardData ::= SEQUENCE >>> { >>> previousNonStandard NonStandardParameter OPTIONAL, >>> extraNonStandard SEQUENCE OF NonStandardParameter, >>> ... >>> } >> >>Please constrain this aggregate with something like this: >> extraNonStandard SET SIZE (0..255) OF NonStandardParameter, >> > >Given that a NonStandardParameter contains a data field that is an >unconstrained OCTET STRING, I don't see the point of arbitrarily >constraining the number of them. > >>> A V1 endpoint could put its own piece of nonStandardData into the >>> existing nonStandard field. When a gatekeeper (or something else) >>> received it, it would take the data from the existing nonStandard field >>> and put it in the previousNonStandard field of the above SEQUENCE. >> >>Copying it or moving it? IOW, would the original nonStandardData still >>be present? >> > >The original nonStandardData is moved, by the first gateway of the >above >example, into the previousNonStandard field. This allows the first >gateway >to add its own NonStandardParameter to the extraNonStandard field. > >The whole ExtendedNonStandardData is placed in the data field of the V1 >NonStandardParameter which is included in the original message in place >of >the original nonStandardData. > >The first proxy does exactly the same thing. > >The message is still V1 compliant so if it goes through anything else >that >cares, it still sees a standard V1 message with the single >NonStandardParameter allowed in the standard and, hopefully, passes it >on >to the second proxy. > >The second proxy recognizes the NonStandardparameter as its very own >and >unwraps it to reveal, in the previousNonStandard field, the >NonStandardParameter that the first proxy received from the first >gatekeeper. It takes its own stuff out and restores the >NonStandardparameter from the previousNonStandard field, places it in >the >outgoing message as the one and only NonStandardParameter allowed in >the >message and sends it to the second gatekeeper. > >The second gatekeeper does exactly the same thing. The message that it >sends to the second endpoint contains the original (from the first >endpoint) NonStandardparameter as received by the first gatekeeper. > >>> It would then add whatever nonStandard stuff it needed to the >>> extraNonStandard bit. It would put the combined nonStandard data in the >>> data part of the nonStandardParameter and give it the tag that we decide >>> on. >> >>I don't understand, why have "previousNonStandard?" Why not just have a >>single nonStandard SET SIZE (0..255) OF NonStandardParameter, and simply >>append any GK stuff to the end? Also, as someone said previously in this >>thread, what if a third-party stack uses the single, original >>NonStandardParameter, yet the layer above that stack also wishes to >>include NonStandardParameters. Sounds like NonStandardParameters can be >>added and removed at any point in the data path, not just by GKs. >> > >In V1, there is only a single nonStandard, not a set of them. To >include a >NonStandardParameter where there alreay is one requires the original to >be >discarded which is the root of the problem. To extend the standard to >have >a SET or SEQUENCE OF is a possible solution to the problem. If the >message >goes through something that only tollerates a single >NonStandardParameter >as specified in the standard, there could be a problem. > >[cut] > >>> I've used an unconstrained SEQUENCE OF for the following reasons: >>> 1. No other SEQUENCE OFs are bounded within H.225. >> >>They should have been, and this will cause implementation problems down >>the line. Each vendor guesses what the max should be. Although all >>guesses are equally "correct," some will be too low and could cause the >>system to fail through no fault of the vendor. Remember that not all >>implementations will have 32MB of RAM and all the virtual memory they >>need. >> > >I understand your concern but, again, the NonStandardParameter is >unbounded >(if I correctly interpret 'OCTET STRING') and so, limiting the number >of >them to 255 doesn't add a lot and imposes an arbitrary constraint. > >>> 2. Size constraints on SEQUENCE OF are not always that useful >>> (especially in the case of H.245!) >> >>I have no idea what you mean by this. There are always real size >>constraints--no system has infinite resources. It would just be nice if >>the constraints were agreed upon and stated up front in the >>Recommendation. >> > >If you impose limitations that fit the lowest hardware of today, they >will >be innappropriate for the hardware of this afternoon. If you set the >limits >to handle the growth, does it help today. Say we imposed a limit of a >4GB >today, would it help. If we made that limit 16K today, how would that >impact us later? > >>> 3. We have no other SET OFs in H.225 >> >>So error propagation is a good thing, right? :-) >> > >This bit I agree with, so it probably means I don't understand the >finer >points of difference between sequences and sets, right? :-) > >>> 4. As I understand it, for some strange reason, because the order of the >>> members of a SET OF is intended to be un-important the compiler takes it >>> upon itself to sort the values entered into some form of order!!! This >>> seems a waste of time and is a step best avoided by using SEQUENCE OF. >> >>I've never heard of this before. I'll check with Bancroft. Sounds like a >>bug in the OSS compiler, which by the way we don't use for reasons like >>this. >> > >Sounds like a problem with implementation in a particular compiler, not >a >good basis for setting the direction of a standard. I think that the >*best* >way to avoid such a problem is to fix or replace the compiler. > > >Regards, > >Douglas Clowes >

1 0

Re: Limitation of nonStandardData
by Pete Cordell 04 Dec '97

04 Dec '97

Ernst, Firstly, I don't think there is a problem with H.245 and the changes proposed by Karl look good to me for H.450.x. Only H.225 needs attention. I had assumed that the gatekeepers knew about each other. I agree the solution I proposed doesn't work for the scenario you described, but I'm not sure that it is soluble within the constraints of the existing nonStandardData field. I had considered suggesting something like extraNonStandard in the H323-UU-PDU field, but I thought others might object. However, it makes sense to me! Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >Sent: 04 December 1997 10:35 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Pete, > >maybe I misunderstand the whole matter, but I think all proposals so >far >have a problem with backward compatibility. Let me summarize how I see >the situation: > >If nonStandardData is essential for a call, the call will not succeed >unless both ends have a common understanding of the nonStandardData. > >But there may be cases where a rudimentary service can be provided >based >on standard data, and nonStandardData provide additional value if both >ends understand it. I.e., an endpoint can communicate with endpoints >from other vendors, but if it communicates with an endpoint from the >same vendor some additional proprietary features are available. This is >the idea behind the extension fields in H.450.x. > >Now, regarding the limitation problem: > >- In H.450.x the limitation concerns only Type NonStandardParameter, >extensions in the ISO style can already be repeated. If there is >sufficient justification, I am sure we remove the limitation before >publication, along the lines indicated by Karl. > >- In H.245, I noticed there are already SEQUENCE OF >NonStandardParameter >at various places, so I assume there is no problem. > >- In H.225.0, we should aim for backwards compatibility. This >eliminates >the possibilty to replace NonStandardParameter by a SET OF or SEQUENCE >OF NonStandardParameter. > >But your proposal of embedding a new structure into the data part of >NonStandardParameter has a similar problem: Suppose a V1 endpoint sends >nonStandardData, and a V2 gatekeeper replaces it with another element >(with another identifier), containing the original nonStandardData in >the previousNonStandard field. There is no guarantee that another GK >unwraps the original nonStandardData again, in which case the new >element will end up at the destination endpoint. If this is V1 it will >not recognize this element, although it may well understand the >original >nonStandardData wrapped inside it. So it cannot act on the information. > >In my opinion, the only way to achieve backwards compatibility is to >add >extraNonStandard as a new element, and there are many places where this >has to be done! > >Example: > >McuInfo ::= SEQUENCE >{ > nonStandardData NonStandardParameter OPTIONAL, > ..., > extraNonStandard SEQUENCE OF NonStandardParameter OPTIONAL >} > >Ernst >================================ >Ernst Horvath >Siemens AG >Tel: +43 1 1707 45897 >Fax: +43 1 1707 56992 >enail: ernst.horvath(a)siemens.at >================================ > >Pete Cordell wrote: >> >> Jim, Scott, Douglas, Paul,..... >> >> To answer Paul's question about the need for the change first: >> >> We are mainly interested in gatekeepers. We have a need to ship >> nonStandard information between cooperating gatekeepers, particularly >in >> the SETUP message. However, endpoints may also wish to ship their own >> nonStandard information which the gatekeeper doesn't want to stamp on >> (because I'm a nice guy!). Hence we both have a need to use a field >> that is only intended to carry one value. >> >> This helps identify a suitable syntax for the data that goes into the >> data part of nonStandard data, as I believe we need to cater for both >> the nested form (for backwards compatibility) and multiple pieces of >> nonStandard data without any particular order. >> >> To do this, I propose that the piece of ASN.1 put in the data part of >> nonStandardParameter should be: >> >> ExtendedNonStandardData ::= SEQUENCE >> { >> previousNonStandard NonStandardParameter OPTIONAL, >> extraNonStandard SEQUENCE OF NonStandardParameter, >> ... >> } >> >> This would be used as follows: >> >> A V1 endpoint could put its own piece of nonStandardData into the >> existing nonStandard field. When a gatekeeper (or something else) >> received it, it would take the data from the existing nonStandard >field >> and put it in the previousNonStandard field of the above SEQUENCE. It >> would then add whatever nonStandard stuff it needed to the >> extraNonStandard bit. It would put the combined nonStandard data in >the >> data part of the nonStandardParameter and give it the tag that we >decide >> on. >> >> On the other side a gatekeeper could see that the extraNonStandard >> related to it, and remove parts the parts that it needed to. If all >> that was left was the previousNonStandard part, then it would use this >> to recover what was the original format of the nonStandard message. >> This allows endpoints to send nonStandardData transparently, but also >> allows gatekeepers to get in on the act. >> >> As far as how this is captured in the standard, this seems a fairly >> important feature for H.225. I think we should include this as a >> separate root in the H.225 ASN.1 and give a fairly official OBJECT >> IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which >> shouldn't clash with anything in the context that we are using it). >> >> I've used an unconstrained SEQUENCE OF for the following reasons: >> 1. No other SEQUENCE OFs are bounded within H.225. >> 2. Size constraints on SEQUENCE OF are not always that useful >> (especially in the case of H.245!) >> 3. We have no other SET OFs in H.225 >> 4. As I understand it, for some strange reason, because the order of >the >> members of a SET OF is intended to be un-important the compiler takes >it >> upon itself to sort the values entered into some form of order!!! >This >> seems a waste of time and is a step best avoided by using SEQUENCE OF. >> >> Pete >> ================================= >> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================= >> >

1 0

Re: Limitation of nonStandardData
by Ernst Horvath 04 Dec '97

04 Dec '97

Pete, maybe I misunderstand the whole matter, but I think all proposals so far have a problem with backward compatibility. Let me summarize how I see the situation: If nonStandardData is essential for a call, the call will not succeed unless both ends have a common understanding of the nonStandardData. But there may be cases where a rudimentary service can be provided based on standard data, and nonStandardData provide additional value if both ends understand it. I.e., an endpoint can communicate with endpoints from other vendors, but if it communicates with an endpoint from the same vendor some additional proprietary features are available. This is the idea behind the extension fields in H.450.x. Now, regarding the limitation problem: - In H.450.x the limitation concerns only Type NonStandardParameter, extensions in the ISO style can already be repeated. If there is sufficient justification, I am sure we remove the limitation before publication, along the lines indicated by Karl. - In H.245, I noticed there are already SEQUENCE OF NonStandardParameter at various places, so I assume there is no problem. - In H.225.0, we should aim for backwards compatibility. This eliminates the possibilty to replace NonStandardParameter by a SET OF or SEQUENCE OF NonStandardParameter. But your proposal of embedding a new structure into the data part of NonStandardParameter has a similar problem: Suppose a V1 endpoint sends nonStandardData, and a V2 gatekeeper replaces it with another element (with another identifier), containing the original nonStandardData in the previousNonStandard field. There is no guarantee that another GK unwraps the original nonStandardData again, in which case the new element will end up at the destination endpoint. If this is V1 it will not recognize this element, although it may well understand the original nonStandardData wrapped inside it. So it cannot act on the information. In my opinion, the only way to achieve backwards compatibility is to add extraNonStandard as a new element, and there are many places where this has to be done! Example: McuInfo ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, ..., extraNonStandard SEQUENCE OF NonStandardParameter OPTIONAL } Ernst ================================ Ernst Horvath Siemens AG Tel: +43 1 1707 45897 Fax: +43 1 1707 56992 enail: ernst.horvath(a)siemens.at ================================ Pete Cordell wrote: > > Jim, Scott, Douglas, Paul,..... > > To answer Paul's question about the need for the change first: > > We are mainly interested in gatekeepers. We have a need to ship > nonStandard information between cooperating gatekeepers, particularly in > the SETUP message. However, endpoints may also wish to ship their own > nonStandard information which the gatekeeper doesn't want to stamp on > (because I'm a nice guy!). Hence we both have a need to use a field > that is only intended to carry one value. > > This helps identify a suitable syntax for the data that goes into the > data part of nonStandard data, as I believe we need to cater for both > the nested form (for backwards compatibility) and multiple pieces of > nonStandard data without any particular order. > > To do this, I propose that the piece of ASN.1 put in the data part of > nonStandardParameter should be: > > ExtendedNonStandardData ::= SEQUENCE > { > previousNonStandard NonStandardParameter OPTIONAL, > extraNonStandard SEQUENCE OF NonStandardParameter, > ... > } > > This would be used as follows: > > A V1 endpoint could put its own piece of nonStandardData into the > existing nonStandard field. When a gatekeeper (or something else) > received it, it would take the data from the existing nonStandard field > and put it in the previousNonStandard field of the above SEQUENCE. It > would then add whatever nonStandard stuff it needed to the > extraNonStandard bit. It would put the combined nonStandard data in the > data part of the nonStandardParameter and give it the tag that we decide > on. > > On the other side a gatekeeper could see that the extraNonStandard > related to it, and remove parts the parts that it needed to. If all > that was left was the previousNonStandard part, then it would use this > to recover what was the original format of the nonStandard message. > This allows endpoints to send nonStandardData transparently, but also > allows gatekeepers to get in on the act. > > As far as how this is captured in the standard, this seems a fairly > important feature for H.225. I think we should include this as a > separate root in the H.225 ASN.1 and give a fairly official OBJECT > IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which > shouldn't clash with anything in the context that we are using it). > > I've used an unconstrained SEQUENCE OF for the following reasons: > 1. No other SEQUENCE OFs are bounded within H.225. > 2. Size constraints on SEQUENCE OF are not always that useful > (especially in the case of H.245!) > 3. We have no other SET OFs in H.225 > 4. As I understand it, for some strange reason, because the order of the > members of a SET OF is intended to be un-important the compiler takes it > upon itself to sort the values entered into some form of order!!! This > seems a waste of time and is a step best avoided by using SEQUENCE OF. > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= >

1 0

Re: Limitation of nonStandardData and other issues related to H.450
by Karl Klaghofer 03 Dec '97

03 Dec '97

Some comments related to H.450.x have been placed to the reflector the last days. 1) H.450.2 Clause 10.5 (item 1 of Levin Orit´s comments, dated Dec.1) I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... should be deleted. 2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit´s comments, dated Dec.1) The procedures defined for this gatekeeper active transfer case right now are very much based on the gatekeeper having H.225 as well as H.245 control (i.e. H.225 as well as H.245 routed via gk). The model you are referring to (H.225 via gk; H.245 direct routed) was not investigated in conjunction with active gk transfer, since this model is (as Pete sayd) still marked as "for further study" in H.323V2 ! Using the direct H.245 model in conjunction with active transfer by gatekeeper would introduce a further, alternative method of handling the logical channel closing and reopening issue at the transferred endpoint B. Remark: In Sunriver September meeting, the goal was to have just one method (we picked the "empty terminalCapabilitySet" method and dropped the "requestChannelClose with reopen" method in order to reach this goal. Proposal for further proceeding: First the H.245 direct model has to be investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might be updated to get this model also to work for active gk transfer. 3) Limitation of nonStandardData (Comment from Pete Cordell, dated Dec.2) Currently we have in H.450.x constructs like the following: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} ExtensionSet EXTENSION ::= {...} -- Actual values defined by individual manufacturers This means: either one value nonStandardParameter or a SEQ of an arbitrary number of values of type Extension may be inserted. 1st possible change: allow more than one nonStandardParameter: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData SEQUENCE OF NonStandardParameter } OPTIONAL which means either a SEQ of Extensions or a SEQ of NonStandardParameter may be inserted. This 1st possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245. 2nd possible change: argumentExtension SEQUENCE OF MixedExtension OPTIONAL MixedExtension ::= CHOICE {extension Extension{{ExtensionSet}}, nonStandardData NonStandardParameter } This 2nd possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245, which adds a further dimension of allowing mixing of any number of NonStandardParameter and ISO like Extensions within one pdu. This may have advantages e.g. in the case that an ISO like Extension is contained within a received pdu in a gk and the gk wants to add further extensions of the NonStandardParamter type (or vice versa) to the same pdu. Proposal for further proceeding. The 2nd possibility mentioned above should be added to a H.450V2. ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ==================================================

2 1

uuencoded file
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Jim, I have noticed that my text file uuencoded on SPARC loses spaces at the end of line, which causes problem for uudecoding. I have confirmed that if it is returned from GCL server nothing happens. I wonder if this redundancy reduction is taking place at your server and if there is any setting to avoid this. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

2 1

Re: Limitation of nonStandardData and other issues related to H.450
by Pete Cordell 03 Dec '97

03 Dec '97

Karl, Your 2nd option looks good to me too... Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Karl Klaghofer[SMTP:karl.klaghofer@MCH.PN.SIEMENS.DE] >Sent: 03 December 1997 09:40 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData and other issues related to >H.450 > >Some comments related to H.450.x have been placed to the reflector the >last days. > >1) H.450.2 Clause 10.5 (item 1 of Levin Orit's comments, dated Dec.1) >I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... >should be deleted. > > >2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit's comments, dated >Dec.1) >The procedures defined for this gatekeeper active transfer case right >now are very much based on the gatekeeper having H.225 as well as H.245 >control (i.e. H.225 as well as H.245 routed via gk). >The model you are referring to (H.225 via gk; H.245 direct routed) was >not investigated in conjunction with active gk transfer, since this >model is (as Pete sayd) still marked as "for further study" in H.323V2 >! >Using the direct H.245 model in conjunction with active transfer by >gatekeeper would introduce a further, alternative method of handling >the logical channel closing and reopening issue at the transferred >endpoint B. Remark: In Sunriver September meeting, the goal was to >have just one method (we picked the "empty terminalCapabilitySet" >method and dropped the "requestChannelClose with reopen" method in >order to reach this goal. >Proposal for further proceeding: First the H.245 direct model has to be >investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might >be updated to get this model also to work for active gk transfer. > > >3) Limitation of nonStandardData (Comment from Pete Cordell, dated >Dec.2) >Currently we have in H.450.x constructs like the following: > >argumentExtension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter } OPTIONAL > >ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} > >ExtensionSet EXTENSION ::= {...} -- Actual values defined by >individual >manufacturers > >This means: either one value nonStandardParameter or a SEQ of an >arbitrary number of values of type Extension may be inserted. > > >1st possible change: allow more than one nonStandardParameter: > >argumentExtension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData SEQUENCE OF NonStandardParameter } >OPTIONAL > >which means either a SEQ of Extensions or a SEQ of NonStandardParameter >may be inserted. This 1st possibility would be a H.450 change >corresponding to Pete's proposal for H.225/H.245. > >2nd possible change: > >argumentExtension SEQUENCE OF MixedExtension OPTIONAL > >MixedExtension ::= CHOICE > {extension Extension{{ExtensionSet}}, > nonStandardData NonStandardParameter } > >This 2nd possibility would be a H.450 change corresponding to Pete's >proposal for H.225/H.245, which adds a further dimension of allowing >mixing of any number of NonStandardParameter and ISO like Extensions >within one pdu. >This may have advantages e.g. in the case that an ISO like Extension is >contained >within a received pdu in a gk and the gk wants to add further >extensions of the NonStandardParamter type (or vice versa) to the same >pdu. >Proposal for further proceeding. The 2nd possibility mentioned above >should be added >to a H.450V2. > >================================================== >Karl Klaghofer >Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany >Dptmnt: PN VS LP3, Building/Room: 1760/455 >Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 >email: karl.klaghofer(a)mch.pn.siemens.de >================================================== >

1 0

Update of the APC-1305 H.245 based control
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Ms. Li Yan and other Q.12/16 experts, To assist the H.bmultipoint Editor (Mr. Hidenobu Harasakai), I have undertaken to update your APC-1305 to reflect the Sunriver meeting discussions as attached. The file sct_X.doc is also placed at the Incoming directory of the GCL ftp site. At this stage, no new materials have been added, but obviously we need such efforts subsequently. Please review this update for inclusion in the draft H.bmultipoint which will soon be issued by Editor with other elaborations. Please also note the following: 1. Simple editorial corrections, such as subject-verb correspondence, have been made without change marks. 2. Another communication procedure section for video mixing? Perhaps not. We can easily extend Section X to cover video mixing from the procedure perspective. It would be better to address basic communication procedures with and without video mixing, but using H.245 and H.310 controls. 3. Another communication procedure section for point-to-multipoint configuration? 4. Add the following definitions: selected communication mode (SCM): a communication mode which MCU identifies to use in a particular multipoint communication session. See H.243. primary terminal: a terminal which supports the SCM. See H.243. secondary terminal: a terminal which does not support the SCM. See H.243. 5. In Section X.4c), I have changed "frame alignment is lost" to "video decoding process may be disrupted" because frame alignment may imply that of H.221. There is no corresponding "frame" in H.222.1/0. 6. In the bit rate symmetry description in Section X.5.1, "MCU may choose to send H.245 FlowControlCommand to achieve the bit-rate symmetry." has been stated according to the discussion in Sunriver (see Section 4.3.2/APC-1327). This is based on my understanding that audio, video and data rates can be controlled either by H.245 FlowControlCommand or RequestMode. However, the transfer rate can only be controlled by H.245 FlowControlCommand. Is my understanding correct? Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** begin 666 sect_X.doc MT,\1X*&Q&N$ .P # /[_"0 & ! M 0 $ @ $ #^____ #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]____)@ /[___\G !0 8 ' M" D * "P P - #@ \ 0 $0 !( 3 M % !4 6 %P !@ 9 &@ !L < '0 !X M ? ( "$ B (P "0 E * /[____^____*0 M "H K + "T N +P # Q ,@ #, T M-0 #8 W . #D #^________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________P!2 M M " 4 __________\# D" # 1@ M ( X73<# +T! P ( " 0!# &\ ;0!P $\ 8@!J M M !( @'_______________\ M 7 !7 &\ <@!D $0 ;P!C '4 ;0!E &X = M &@ " ?__ M__\$ _____P M 0 !Q9P $\ 8@!J &4 8P!T % ;P!O &P M 6 $! 0 ( #_ M____ HL0V P"] 0"BQ#8# +T! M 0 /[___\# ! 4 & !P @ ) _O__ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________________\! /[_ @ ! /____\ "0( , M !&' $UI8W)O<V]F="!7;W)D(#8N,"!$;V-U;65N= #^____3D(V M5Q !7;W)D+D1O8W5M96YT+C8 [ /__@ ) 8 M 0 $ 0 /[_ #"@$ $ #R MGX7@3_D0:*N1" K)[/9, +T! / !P )@ " XP 0 M B 0 " #(! ! 0@$ P !( 0 "P %0! - 8 $ M \ !L 0 $ '0! * ? $ !( "( 0 #@ *,! ) MJP$ !, "U 0 ! 0 ! /__________'@ $, !- M86-I;G1O<V@@2$0Z07!P;&EC871I;VYS.H./@5N#:(-V@XV#6H-B@U0Z5V]R M9" V.E1E;7!L871E<SI.;W)M86P '@ #< !8+@E"87-I8R!C;VUM=6YI M8V%T:6]N('!R;V-E9'5R97,@=7-I;F<@2"XR-#4@8V]N=')O;', '@ @ M !A:V%S86MA !X ( 86MA<V%K80 " $2= ,2*'-RE: !# MP D$ &4 $ $ 0 # #,00 <6< M #*/@ 0 8@ Y@ M !B #F YF( #F8@ .9B $ ZF( @ #R8@ M% &QC ;&, !L8P &QC ;&, !L M8P (@ (YC ! ;&, !T9@ 30 1D !&0 M $9 1D $ "&0 (9 AD "&0 M !,9@ @ $YF 3F8 !.9@ $YF M3F8 !.9@ )@ ,%F !8 &6< %@ !T9@ M #F8@ AD B "< !0 * AD M"&0 "&0 (9 '1F M "&0 #F8@ .9B "&0 M SF, #8 (9 AD "&0 (9 M .9B "&0 #F8@ AD 3&8 M !F, "8 L8P 0 .9B YF( #F M8@ .9B "&0 !,9@ AD !$ @ "&0 M M %@) M0F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S('5S:6YG($@N,C0U(&-O M;G1R;VQS#0U8+C$)1V5N97)A; T-5&AI<R!S96-T:6]N('-P96-I9FEE<R!T M:&4@;75L=&EP;VEN="!C;VYF97)E;F-E('-E<W-I;VX@8V]N=')O;"!U<VEN M9R!C;&%S<VEC86P@34-5*',I('=I=&AO=70@=FED96\@;6EX:6YG('=H97)E M(&5N9'!O:6YT<R!A<F4@=&EG:'1L>2UC;W5P;&5D+B!!=61I;R!I<R!C96YT M<F%L;'D@;6EX960@86YD('9I9&5O("AA;F0@9&%T82D@87)E(&-E;G1R86QL M>2!S=VET8VAE9"!A="!T:&4@34-5+B!4;R!P<F]V:61E(&)A<VEC(&-O;F9E M<F5N8V4@<V5S<VEO;B!C;VYT<F]L<RP@=&AE(&-O;6UU;FEC871I;VX@<')O M8V5D=7)E<R!A<F4@8F%S960@;VX@2"XR-#,@=7-I;F<@2"XR-#4@;65S<V%G M97,@86YD($@N,S$P(%9I9&5O($9R86UE(%-Y;F-H<F]N;W5S($,F22!S:6=N M86QL:6YG+@T-6"XR"5!R;V-E9'5R92!F;W(@9&5T97)M:6YI;F<@8V%P86)I M;&ET:65S(&%N9"!S96QE8W1E9"!C;VUM=6YI8V%T:6]N(&UO9&4-#51H92!- M0U4@<VAA;&P@<V5N9"!A<'!R;W!R:6%T92!C87!A8FEL:71I97,L(&%C8V]R M9&EN9R!T;R!T:&4@='EP92!O9B!C;VUM=6YI8V%T:6]N(&EN=&5N9&5D+B!& M;W(@96%C:"!C;VYF97)E;F-E(&-A;&P@82"3<V5L96-T960@8V]M;75N:6-A M=&EO;B!M;V1E("A30TTIE"!I<R!I9&5N=&EF:65D(&EN('1H92!-0U4N($1U M<FEN9R!T:&4@8V%L;"!T:&4@34-5('-T<FEV97,@=&\@;6%I;G1A:6X@=&AI M<R!30TT@87,@=&AA="!T<F%N<VUI='1E9"!B:2UD:7)E8W1I;VYA;&QY(&)E M='=E96X@:71S96QF(&%N9"!A;&P@=&5R;6EN86QS+"!A;F0@8F5T=V5E;B!I M='-E;&8@86YD(&]T:&5R($U#57,N( T-5&AE(&9O;&QO=VEN9R!A<F4@<&]S M<VEB;&4@;65T:&]D<R!T;R!D971E<FUI;F4@=&AE(%-#33H-#71H92!30TT@ M;6%Y(&)E(&9I>&5D(&%S(&$@<&5R;6%N96YT(&9E871U<F4@;V8@=&AE($U# M52!A<R!M86YU9F%C='5R960[#71H92!-0U4@;6%Y('!R;W9I9&4@9F]R('-E M=F5R86P@<&]S<VEB;&4@=F%L=65S(&]F(%-#32P@86YD(&]N92!O9B!T:&5S M92!I<R!S<&5C:69I960@8GD@=&AE('-E<G9I8V4@<')O=FED97(@;W(@870@ M=&AE('1I;64@;V8@8F]O:VEN9R!T:&4@8V%L;#L-=&AE(%-#32!I<R!S96QE M8W1E9"!A=71O;6%T:6-A;&QY('=I=&AI;B!T:&4@34-5(&%C8V]R9&EN9R!T M;R!T:&4@8V%P86)I;&ET:65S(&]F('1H92!T97)M:6YA;',@8V]N;F5C=&5D M.R!F;W(@97AA;7!L92P@=&AE(%-#32!I<R!S970@870@=&AE('9A;'5E('1R M86YS;6ET=&5D(&)Y('1H92!F:7)S="!T97)M:6YA;"!T;R!A8V-E<W,@=&AE M($U#53L@;W(@=&AE(&AI9VAE<W0@8V]M;6]N(&UO9&4@;V8@86QL('!R:6UA M<GD@=&5R;6EN86QS(&ES('-E;&5C=&5D.R!O<B!T:&4@4T--(&ES('-E="!A M="!T:&4@=F%L=64@=')A;G-M:71T960@8GD@=&AE(&-H86ER+6-O;G1R;VP@ M=&5R;6EN86PL(&EF(&%N>3L-=&AE(%-#32!I<R!S970@8GD@=71I;&EZ:6YG M('!R;V-E9'5R97,@969F96-T=6%T960@=7-I;F<@5"XQ,C @4V5R:65S('!R M;W1O8V]L<RX-#51O(&5N9F]R8V4@4T--+"!A="!T:&4@8F5G:6YN:6YG(&]F M(&$@8V]N9F5R96YC92P@34-5('-E;F1S(&UU;'1I<&]I;G1-;V1E0V]M;6%N M9"!T;R!A;&P@=&AE('1E<FUI;F%L<R!T;R!C;VUM86YD('1H870@82!T97)M M:6YA;"!I;B!R96-E:7!T('-H86QL(&-O;7!L>2!W:71H(&%L;"!R97%U97-T M36]D92!R97%U97-T<R!I<W-U960@8GD@=&AE($U#52P@:68@=&AE(')E<75E M<W1E9"!T<F%N<V9E<B!M;V1E(&ES('=I=&AI;B!T97)M:6YA;))S(&-A<&%B M:6QI='D@<V5T+@T-6"XS"4EN:71I86QI>F%T:6]N('!R;V-E9'5R97,@9F]R M(&5S=&%B;&ES:&EN9R!C;VUM=6YI8V%T:6]N(&)E='=E96X@<W1A;F1A<F0@ M=&5R;6EN86QS(&%N9"!A;B!-0U4-#5@N,RXQ"49I<G-T('1E<FUI;F%L(&%D M9&5D('1O(&-O;F9E<F5N8V4-#51H92!C;VUM=6YI8V%T:6]N(&]F('1H92!F M:7)S="!T97)M:6YA;" H5#$I(&%N9"!-0U4@9F]L;&]W<R!T:&4@9F]L;&]W M:6YG('!H87-E<SH-#5!H87-E($$Z($-A;&P@<V5T=7 @*$EN:71I86P@5D,M M4V5T=7 I.@T-26YI=&EA;"!60R!I<R!S971U<"!B971W965N('1H92!F:7)S M="!T97)M:6YA;"!A;F0@=&AE($U#52!V:6$@42XR.3,Q(%-%5%50(&UE<W-A M9V4N(%1H92!E>&%C="!P87)A;65T97)S(&%N9"!1+C(Y,S$@26YF;W)M871I M;VX@16QE;65N=',@*$E%<RD@=7-E9"!F;W(@=&AI<R!P:&%S92!A<F4@9&5S M8W)I8F5D(&EN($@N,S$P($%N;F5X($(N($EN('1H:7,@<&AA<V4L($U#52!C M86X@96ET:&5R(&ED96YT:69Y('1H92!T>7!E(&]F(')E;6]T92!(+C,Q,"!T M97)M:6YA;"!O<B!I;F9E<B!T:&%T('1H92!R96UO=&4@=&5R;6EN86P@:7,@ M;F]T($@N,S$P('1E<FUI;F%L('1Y<&4N(%1H:7,@:7,@9&]N92!B>2!U<VEN M9R!T:&4@0G)O861B86YD($)E87)E<B!#87!A8FEL:71Y("A"+4)#*2P@3F%R M<F]W+6)A;F0@0F5A<F5R($-A<&%B:6QI='D@*$XM0D,I(&%N9"!O=&AE<B!I M;F9O<FUA=&EO;B!E;&5M96YT<R!O9B!T:&4@42XR.3,Q(%-%5%50(&UE<W-A M9V4N($%N($@N8FUU;'1I<&]I;G0S,3 @34-5('-H86QL('-E="!T:&5S92!I M;F9O<FUA=&EO;B!E;&5M96YT<R!T;R!T:&4@87!P<F]P<FEA=&4@<&%R86UE M=&5R<R!W:&EC:"!I;F1I8V%T92!T:&4@2"XS,3 @=&5R;6EN86P@='EP92X@ M268@86X@2"YB;75L=&EP;VEN=#,Q,"!D;V5S(&YO="!R96-E:79E('1H92!. M+4)#(&EN9F]R;6%T:6]N(&5L96UE;G0@9G)O;2!T:&4@<F5M;W1E('1E<FUI M;F%L+"!T:&5N('1H92!(+C,Q,"!-0U4@8V%N(&%S<W5M92!T:&%T(&ET(&ES M(&YO="!C;VUM=6YI8V%T:6]N('=I=&@@86X@2"XS,C O2"XS,C$@=&5R;6EN M86PN#0U4:&4@:6YI=&EA;"!60R!S:&%L;"!H879E(&$@8FET(')A=&4@;V8@ M-C0@:V)I="]S(&%T('1H92!!04PM4T%0+"!F;W(@=&AE('1R86YS9F5R(&]F M($@N,C0U(&UE<W-A9V5S('5S:6YG('1H92!S97!A<F%T92!60R!S=&%C:R!D M97-C<FEB960@:6X@2"XS,3 @06YN97@@02X-#5!H87-E($(Z($EN:71I86P@ M8V]M;75N:6-A=&EO;B!A;F0@0V%P86)I;&ET>2!E>&-H86YG92 -#4U#52!S M96YD<R!M=6QT:7!O:6YT0V]N9F5R96YC92!A;F0@;75L=&EP;VEN=%IE<F]# M;VUM(&EN9&EC871I;VYS('1O('1H92!F:7)S="!T97)M:6YA;"!O=F5R('1H M92!I;FET:6%L(%9#('1H870@:&%S(&)E96X@97-T86)L:7-H960@:6X@4&AA M<V4@02P@:6YD:6-A=&EN9R!T:&%T(&$@8V]N9F5R96YC92!C86QL(&ES(&)E M:6YG('-E="!U<"P@=&AA="!N;R!O=&AE<B!T97)M:6YA;',@87)E('EE="!C M;VYN96-T960@86YD('1H92!U<V5R('-H;W5L9"!W86ET+B!5<VEN9R!(+C(T M-2 @<')O8V5D=7)E<RP@=&AE($U#52!A;F0@=&AE(&9I<G-T('1E<FUI;F%L M(&5X8VAA;F=E('1H96ER(&-A<&%B:6QI=&EE<RX@34-5(')E9VES=&5R<R!T M:&]S92!C87!A8FEL:71I97,@;V8@=&AE(&9I<G-T('1E<FUI;F%L('=H:6-H M(&ET(&-A;B!U;F1E<G-T86YD(&%N9"!U<V4N($9O<B!T:&]S92!C87!A8FEL M:71I97,@=&AA="!A<F4@;F]T('5N9&5R<W1O;V0L(&]R(&-A;B!N;W0@8F4@ M=7-E9"!B>2!-0U4@<VAA;&P@8F4@:6=N;W)E9"X@3F]T92!T:&%T($U#52!C M86X@9&5T97)M:6YE()-30TV4("!B87-E9"!O;B!T:&4@8V%P86)I;&ET:65S M(&5X8VAA;F=E(&]R('5S92!P<F5D971E<FUI;F5D()-30TV4(&%S(&1E<V-R M:6)E9"!I;B"D6"XS+C$N#0U-0U4@=&AE;B!S96YD<R!M=6QT:7!O:6YT36]D M94-O;6UA;F0@8V]M;6%N9"!T;R!R97%U97-T('1H92!F:7)S="!T97)M:6YA M;"!T;R!F;VQL;W<@86QL(&UO9&4@<F5Q=65S=',@9G)O;2!I="X@5&AE;B!- M0U4@<V5N9',@4F5Q=65S=$UO9&4@=VET:"!A(&QI<W0@;V8@<V5L96-T960@ M8V]M;75N:6-A=&EO;B!M;V1E<RX-#5!H87-E($,Z($5S=&%B;&ES:&UE;G0@ M;V8@875D:6]V:7-U86P@8V]M;75N:6-A=&EO;B H061D:71I;VYA;"!60R!3 M971U<"!A;F0@02]6(&-O;6TN*0T-26X@=&AI<R!P:&%S92P@86YD(&)A<V5D M(&]N('1H92!S96QE8W1E9"!C;VUM=6YI8V%T:6]N(&UO9&4@9&5T97)M:6YE M9"!A8F]V92P@=&AE(&-A;&QI;F<@<&%R='D@*&-A;B!B92!-0U4@;W(@=&AE M(&9I<G-T('1E<FUI;F%L*2P@=&AA="!I<RP@=&AE(&]N92!T:&%T(&EN:71I M871E9"!T:&4@9FER<W0@5D,@4T5455 @;65S<V%G92P@<VAA;&P@9FER<W1L M>2!I;F1I8V%T92!T:&4@8VAA<F%C=&5R:7-T:6-S(&]F('1H92!A9&1I=&EO M;F%L(%9#*',I('1O('1H92!R96UO=&4@96YD('5S:6YG('1H92!(+C(T-2!. M97=!5$U60TEN9&EC871I;VX@;65S<V%G92P@86YD('1H96X@<VAA;&P@<V5T M('5P('1H92!A9&1I=&EO;F%L(%9#*',I('=I=&@@=&AE(&%P<')O<')I871E M('!A<F%M971E<G,L('-U8V@@87,@8FET(')A=&4@86YD($%!3"!T>7!E+"!F M;W(@=&AE('1R86YS9F5R(&]F('1H92!A=61I;W9I<W5A;"!A;F0@;W1H97(@ M9&%T82!B971W965N('1H92!-0U4@86YD('1H92!F:7)S="!T97)M:6YA;"X@ M069T97(@97-T86)L:7-H;65N="!O9B!T:&4@861D:71I;VYA;"!60RAS*2P@ M=&AE('!R;V-E9'5R97,@;V8@2"XR-#4@<VAA;&P@8F4@=7-E9"!T;R!O<&5N M('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD+V]R(&-O;G1R M;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!L;V=I8V%L(&-H86YN96P@<VEG M;F%L;&EN9R!P<F]T;V-O;"!A;F0@8FDM9&ER96-T:6]N86P@;&]G:6-A;"!C M:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@9&5F:6YE9"!I;B!(+C(T-2X- M#51O(&%V;VED(&)A9"!A=61I;RP@870@=&AE(&1I<V-R971I;VX@;V8@=&AE M(&UA;G5F86-T=7)E<BP@=&AE($U#52!S:&]U;&0@9&\@;VYE(&]F('1H92!F M;VQL;W=I;F<@9F]R(&%U9&EO.@T-<V5N9"!L;V=I8V%L0VAA;FYE;$EN86-T M:79E(&9O<B!T:&4@875D:6\@8VAA;FYE;"!T;R!T:&4@=&5R;6EN86P[#7-E M;F0@<VEL96YC92!O<B!A;B!O<'1I;VYA;"!A=61I;RUM97-S86=E('1O('1H M92!T97)M:6YA;"X-#51H92!V:61E;R!S965N(&)Y('1H92!F:7)S="!T97)M M:6YA;"!I<R!U<"!T;R!T:&4@9&ES8W)E=&EO;B!O9B!T:&4@34-5(&UA;G5F M86-T=7)E<BX-#51H92!D871A(')E8V5I=F5D(&)Y('1H92!F:7)S="!T97)M M:6YA;"!I<R!U<"!T;R!T:&4@9&ES8W)E=&EO;B!O9B!T:&4@34-5(&UA;G5F M86-T=7)E<BX-#5@N,RXR"5-E8V]N9"!T97)M:6YA;"!A9&1E9"!T;R!C;VYF M97)E;F-E#0U0:&%S92!!.B!#86QL('-E='5P("A);FET:6%L(%9#+5-E='5P M*3H-#4EN:71I86P@5D,@:7,@<V4@='5P(&)E='=E96X@34-5(&%N9"!T:&4@ M<V5C;VYD('1E<FUI;F%L("A4,BD@8GD@=7-I;F<@=&AE('-A;64@;65T:&]D M(&%S(&EN('1H92!F:7)S="!T97)M:6YA;"X-#5!H87-E($(Z($EN:71I86P@ M8V]M;75N:6-A=&EO;B!A;F0@0V%P86)I;&ET>2!E>&-H86YG90T-34-5('-E M;F1S(&UU;'1I<&]I;G1#;VYF97)E;F-E(&EN9&EC871I;VX@=&\@=&AE('-E M8V]N9"!T97)M:6YA;"!O=F5R('1H92!I;FET:6%L(%9#('1H870@:&%S(&)E M96X@97-T86)L:7-H960@:6X@4&AA<V4@02P@:6YD:6-A=&EN9R!T:&%T(&$@ M8V]N9F5R96YC92!C86QL(&ES(&)E:6YG('-E="!U<"X@57-I;F<@2"XR-#4@ M('!R;V-E9'5R97,L('1H92!-0U4@86YD('1H92!S96-O;F0@=&5R;6EN86P@ M97AC:&%N9V4@=&AE:7(@8V%P86)I;&ET:65S+B!-0U4@<F5G:7-T97)S('1H M;W-E(&-A<&%B:6QI='D@;V8@=&AE('-E8V]N9"!T97)M:6YA;',@=VAI8V@@ M:70@8V%N('5N9&5R<W1A;F0@86YD('5S92X@1F]R('1H;W-E(&-A<&%B:6QI M=&EE<R!T:&%T(&%R92!N;W0@=6YD97)S=&]O9"P@;W(@8V%N(&YO="!B92!U M<V5D(&)Y($U#52!S:&%L;"!B92!I9VYO<F5D+B!.;W1E('1H870@34-5(&-A M;B!D971E<FUI;F4@DU-#390@(&)A<V5D(&]N('1H92!C87!A8FEL:71I97,@ M97AC:&%N9V4@;W(@=7-E('!R961E=&5R;6EN960@DU-#390@87,@9&5S8W)I M8F5D(&EN(*18+C,N,2X-#4U#52!T:&5N('-E;F1S(&UU;'1I<&]I;G1-;V1E M0V]M;6%N9"!C;VUM86YD('1O(')E<75E<W0@=&AE('-E8V]N9"!T97)M:6YA M;"!T;R!F;VQL;W<@86QL(&UO9&4@<F5Q=65S=',@9G)O;2!I="X@5&AE;B!- M0U4@<V5N9',@<F5Q=65S=$UO9&4@=VET:"!T:&4@;&ES="!O9B!S96QE8W1E M9"!C;VUM=6YI8V%T:6]N(&UO9&5S+@T-4&AA<V4@0SH@17-T86)L:7-H;65N M="!O9B!A=61I;W9I<W5A;"!C;VUM=6YI8V%T:6]N("A!9&1I=&EO;F%L(%9# M(%-E='5P*0T-26X@=&AI<R!P:&%S92P@86YD(&)A<V5D(&]N('1H92!C;VUM M=6YI8V%T:6]N(&UO9&4@9&5T97)M:6YE9"!A8F]V92P@=&AE(&-A;&QI;F<@ M<&%R='DL('1H870@:7,L('1H92!O;F4@=&AA="!I;FET:6%T960@=&AE(&9I M<G-T(%9#(%-%5%50(&UE<W-A9V4L('-H86QL(&9I<G-T;'D@:6YD:6-A=&4@ M=&AE(&-H87)A8W1E<FES=&EC<R!O9B!T:&4@861D:71I;VYA;"!60RAS*2!T M;R!T:&4@<F5M;W1E(&5N9"!U<VEN9R!T:&4@2"XR-#4@3F5W051-5D-);F1I M8V%T:6]N(&UE<W-A9V4L(&%N9"!T:&5N('-H86QL('-E="!U<"!T:&4@861D M:71I;VYA;"!60RAS*2!W:71H('1H92!A<'!R;W!R:6%T92!P87)A;65T97)S M+"!S=6-H(&%S(&)I="!R871E(&%N9"!!04P@='EP97,L(&9O<B!T:&4@=')A M;G-F97(@;V8@=&AE(&%U9&EO=FES=6%L(&%N9"!O=&AE<B!D871A(&)E='=E M96X@=&AE($U#52!A;F0@=&AE('-E8V]N9"!T97)M:6YA;"X-#4%N($U#52!S M:&%L;"!O<&5N('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD M+V]R(&-O;G1R;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!T:&4@;&]G:6-A M;"!C:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@86YD(&)I+61I<F5C=&EO M;F%L(&QO9VEC86P@8VAA;FYE;"!S:6=N86QL:6YG('!R;W1O8V]L(&1E9FEN M960@:6X@2"XR-#4N(%1H92!A=61I;R!A;F0@=FED96\@<&%T:',@87)E('-E M="!U<"!A<R!F;VQL;W=S.@T-075D:6\Z( U";W1H('1H92 H9&5C;V1E9"D@ M875D:6\@<VEG;F%L<R!A<F4@8V]N;F5C=&5D('1O('1H92!A=61I;R!M:7AE M<CL@=&AE('-Y;6)O;"!C86YC96Q-=6QT:7!O:6YT6F5R;T-O;6T@:7,@<V5N M="!T;R!T:&4@9FER<W0@=&5R;6EN86P@5#$[#51H92!M:7AE<B!O=71P=71S M(&%R92!S96YT('1O(%0Q(&%N9"!4,B!A;F0@=&AE(&UI>&EN9R!A;&=O<FET M:&T@=7-E9"!I<R!U<"!T;R!T:&4@34-5(&UA;G5F86-T=7)E<BX-5FED96\Z M( U)9B!V:61E;R!S:6=N86QS(&%R92!B96EN9R!R96-E:79E9"!F<F]M(&5I M=&AE<B!O<B!B;W1H('1E<FUI;F%L<RP@=FED96]&87-T57!D871E4&EC='5R M92!I<R!S96YT('1O=V%R9',@=&AE('1R86YS;6ET=&5R*',I(&]F('1H97-E M('-I9VYA;',@86YD('1H92!N97AT('9I9&5O(&9R86UE(&EN()-&87-T('5P M9&%T990@;6]D92!I<R!F;W)W87)D960@=&\@8F]T:"!T97)M:6YA;',[#4EF M('9I9&5O('-I9VYA;',@87)E(&)E:6YG(')E8V5I=F5D(&9R;VT@8F]T:"!T M97)M:6YA;',L('9I9&5O1F%S=%5P9&%T95!I8W1U<F4@:7,@<V5N="!T;R!B M;W1H('1E<FUI;F%L<RX@5#&2<R!V:61E;R!I<R!F;W)W87)D960@=&\@5#(L M(&%N9"!4,I)S('9I9&5O(&ES(&9O<G=A<F1E9"!T;R!4,3LN#4EF('9I9&5O M26YD:6-A=&5296%D>51O06-T:79A=&4@:7,@<F5C96EV960@9G)O;2!E:71H M97(@;W(@8F]T:"!T97)M:6YA;',L('1H:7,@:7,@9F]R=V%R9&5D+@U$871A M.B -268@8F]T:"!T97)M:6YA;',@87)E(%0N,3(P(&-A<&%B;&4@=&AE($U# M52!M87D@8V]N;F5C="!B;W1H('1O(&$@9&%T82!C;VYF97)E;F-I;F<@=6YI M="X-5&AE($U#52!M87D@9&5F97(@;W!E;FEN9R!O9B!D871A(&-H86YN96QS M('1O(&$@;&%T97(@=&EM92P@<W5C:"!A<R!W:&5N(&$@<')E9&5T97)M:6YE M9"!N=6UB97(@;V8@=&5R;6EN86QS(&ES('!R97-E;G0N#0U8+C,N,PE4:&ER M9"!T97)M:6YA;"!A9&1E9"!T;R!C;VYF97)E;F-E#0U0:&%S92!!.B!#86QL M('-E='5P("A);FET:6%L(%9#+5-E='5P*3H-#4EN:71I86P@5D,@:7,@<V5T M('5P(&)E='=E96X@34-5(&%N9"!T:&4@=&AI<F0@=&5R;6EN86P@8GD@=7-I M;F<@=&AE('-A;64@;65T:&]D(&%S(&EN('1H92!F:7)S='1H:7)D('1E<FUI M;F%L+@T-4&AA<V4@0CH@26YI=&EA;"!C;VUM=6YI8V%T:6]N(&%N9"!#87!A M8FEL:71Y(&5X8VAA;F=E#0U-0U4@<V5N9',@;75L=&EP;VEN=$-O;F9E<F5N M8V4@:6YD:6-A=&EO;B!T;R!T:&4@=&AI<F0@=&5R;6EN86P@;W9E<B!T:&4@ M:6YI=&EA;"!60R!T:&%T(&AA<R!B965N(&5S=&%B;&ES:&5D(&EN(%!H87-E M($$L(&EN9&EC871I;F<@=&AA="!A(&-O;F9E<F5N8V4@8V%L;"!I<R!B96EN M9R!S970@=7 N(%5S:6YG($@N,C0U("!P<F]C961U<F5S+"!T:&4@34-5(&%N M9"!T:&4@=&AI<F0@=&5R;6EN86P@97AC:&%N9V4@=&AE:7(@8V%P86)I;&ET M:65S+B!-0U4@<F5G:7-T97)S('1H;W-E(&-A<&%B:6QI=&EE<R!O9B!T:&4@ M=&AI<F0@=&5R;6EN86P@=VAI8V@@:70@8V%N('5N9&5R<W1A;F0@86YD('5S M92X@1F]R('1H;W-E(&-A<&%B:6QI=&EE<R!T:&%T(&%R92!N;W0@=6YD97)S M=&]O9"P@;W(@8V%N(&YO="!B92!U<V5D(&)Y($U#52!S:&%L;"!B92!I9VYO M<F5D+B!.;W1E('1H870@34-5(&-A;B!D971E<FUI;F4@DU-#390@(&)A<V5D M(&]N('1H92!C87!A8FEL:71I97,@97AC:&%N9V4@;W(@=7-E('!R961E=&5R M;6EN960@DU-#390@87,@9&5S8W)I8F5D(&EN(*18+C,N,2X-#4U#52!T:&5N M('-E;F1S(&UU;'1I<&]I;G1-;V1E0V]M;6%N9"!C;VUM86YD('1O(')E<75E M<W0@=&AE('1H:7)D('1E<FUI;F%L('1O(&9O;&QO=R!A;&P@;6]D92!R97%U M97-T<R!F<F]M(&ET+B!4:&5N($U#52!S96YD<R!R97%U97-T36]D92!W:71H M('1H92!L:7-T(&]F('-E;&5C=&5D(&-O;6UU;FEC871I;VX@;6]D97,N#0U0 M:&%S92!#.B!%<W1A8FQI<VAM96YT(&]F(&%U9&EO=FES=6%L(&-O;6UU;FEC M871I;VX@#0U);B!T:&ES('!H87-E+"!A;F0@8F%S960@;VX@=&AE(&-O;6UU M;FEC871I;VX@;6]D92!D971E<FUI;F5D(&%B;W9E+"!T:&4@8V%L;&EN9R!P M87)T>2P@=&AA="!I<RP@=&AE(&]N92!T:&%T(&EN:71I871E9"!T:&4@9FER M<W0@5D,@4T5455 @;65S<V%G92P@<VAA;&P@9FER<W1L>2!I;F1I8V%T92!T M:&4@8VAA<F%C=&5R:7-T:6-S(&]F('1H92!A9&1I=&EO;F%L(%9#*',I('1O M('1H92!R96UO=&4@96YD('5S:6YG('1H92!(+C(T-2!.97=!5$U60TEN9&EC M871I;VX@;65S<V%G92P@86YD('1H96X@<VAA;&P@<V5T=7 @=&AE(&%D9&ET M:6]N86P@5D,H<RD@=VET:"!T:&4@87!P<F]P<FEA=&4@<&%R86UE=&5R<RP@ M<W5C:"!A<R!B:70@<F%T92!A;F0@04%,('1Y<&5S+"!F;W(@=&AE('1R86YS M9F5R(&]F('1H92!A=61I;W9I<W5A;"!A;F0@;W1H97(@9&%T82!B971W965N M('1H92!-0U4@86YD('1H92!T:&ER9"!T97)M:6YA;"X-#4%N($U#52!S:&%L M;"!O<&5N('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD+V]R M(&-O;G1R;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!T:&4@;&]G:6-A;"!C M:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@86YD(&)I+61I<F5C=&EO;F%L M(&QO9VEC86P@8VAA;FYE;"!S:6=N86QL:6YG('!R;W1O8V]L(&1E9FEN960@ M:6X@2"XR-#4N(%1H92!A=61I;R!A;F0@=FED96\@<&%T:',@87)E('-E="!U M<"!A<R!F;VQL;W=S.B -#4%U9&EO.B -5&AE("AD96-O9&5D*2!A=61I;R!S M:6=N86P@:7,@8V]N;F5C=&5D('1O('1H92!A=61I;R!M:7AE<CL@( U4:&4@ M;6EX97(@;W5T<'5T<R!A<F4@<V5N="!T;R!A;&P@=&AE('1E<FUI;F%L<R!A M;F0@=&AE(&UI>&EN9R!A;&=O<FET:&T@=7-E9"!I<R!U<"!T;R!T:&4@34-5 M(&UA;G5F86-T=7)E<BX-5FED96\Z( U)9B!V:61E;R!S:6=N86QS(&%R92!B M96EN9R!R96-E:79E9"!F<F]M(&%N>2!O;F4@;V8@=&AE('1E<FUI;F%L<R!4 M,2P@5#(L(&%N9"!4,RP@;W(@86QL(&]F('1H92!T97)M:6YA;',L('9I9&5O M(&ES('-W:71C:&5D('5S:6YG('1H92!P<F]C961U<F5S(&1E<V-R:6)E9"!I M;B"D6"XU+@U$871A.@U)9B!T:&4@;F5W('1E<FUI;F%L(&ES(%0N,3(P(&-A M<&%B;&4L('1H92!-0U4@8V]N;F5C=',@:70@=&\@=&AE(&1A=&$@8V]N9F5R M96YC:6YG('5N:70N#0U8+C,N- E&;W5R=&@@86YD('-U8G-E<75E;G0@8V%L M;',@861D960@=&\@8V]N9F5R96YC90T-5&AE('!R;V-E9'5R92!F;VQL;W=E M9"!I<R!E<W-E;G1I86QL>2!T:&%T(&]F('-E8W1I;VX@,R!A8F]V92X-#5@N M,RXU"4-L;W-U<F4@;V8@8V]N9F5R96YC90T-268@=&AE(&-O;F9E<F5N8V4@ M:7,@8VQO<V5D(&)Y('-E<75E;G1I86QL>2!D<F]P<&EN9R!T97)M:6YA;',L M('1H96X@=VAE;B!O;FQY(&]N92!R96UA:6YS(&-O;FYE8W1E9"!I="!S:&]U M;&0@8F4@<V5N="!M=6QT:7!O:6YT6F5R;T-O;6T@=&\@86QL;W<@=&AE('5S M97(@=&\@=6YD97)S=&%N9"!E>'!L:6-I=&QY('1H92!R96%S;VX@9F]R(&QO M<W,@;V8@=FED96\L(&5T8RX@5&AE('1E<FUI;F%L(&1R;W!P960@9F]L;&]W M<R!T:&4@9F]L;&]W:6YG(&-A;&P@<F5L96%S92!P<F]C961U<F5S('1O(&-L M;W-E('1H92!C;VYN96-T:6]N.@U,;V=I8V%L(&-H86YN96QS(')E;&5A<V4Z M($EN('1H:7,@<&AA<V4L(&%L;"!L;V=I8V%L(&-H86YN96QS(&%R92!C;&]S M960@86YD($5N9%-E<W-I;VY#;VUM86YD(&ES('1R86YS;6ET=&5D+"!U<VEN M9R!T:&4@<')O8V5D=7)E<R!D97-C<FEB960@:6X@2"XR-#4N#59I<G1U86P@ M0VAA;FYE;',@<F5L96%S93H@26X@=&AI<R!P:&%S92P@86QL($%432!60W,@ M87)E(')E;&5A<V5D('5S:6YG('1H92!P<F]C961U<F5S(&1E<V-R:6)E9"!I M;B!1+C(Y,S$N#0U8+C0)5FED96\@4W=I=&-H:6YG( T-5VAE;B!I="!I<R!D M96-I9&5D('=I=&AI;B!T:&4@34-5('1H870@=&5R;6EN86P@02P@8W5R<F5N M=&QY(')E8V5I=FEN9R!T:&4@=FED96\@<VEG;F%L(&9R;VT@=&5R;6EN86P@ M0BP@<VAO=6QD(&EN<W1E860@8F4@<V5N="!F<F]M('1E<FUI;F%L($,L('1H M92!F;VQL;W=I;F<@<')O8V5D=7)E(&ES('5S960Z#0U4:&4@34-5('1R86YS M;6ET<R!V:61E;T9R965Z95!I8W1U<F4@=&\@=&5R;6EN86P@02!A="!A;B!A M<'!R;W!R:6%T92!M;VUE;G0L(&%N9"!T:&5N('-W:71C:&5S('9I9&5O(%1R M86YS<&]R="!3=')E86T@<&%C:V5T<R!S=6-H('1H870@=&AE('!I8W1U<F4@ M9G)O;2!#(&ES('1R86YS;6ET=&5D('1O=V%R9',@03L-5&5R;6EN86P@02!R M96-E:79E<R!V:61E;T9R965Z95!I8W1U<F4L(&%N9"!F<F5E>F5S(&ET<R!C M=7)R96YT;'D@9&ES<&QA>65D('!I8W1U<F4[(&ET(&EG;F]R97,@<W5B<V5Q M=65N="!D96-O9&5D('9I9&5O(&EN9F]R;6%T:6]N+"!B=70@8V]N=&EN=65S M('1O('1R86-K('1H92!V:61E;R!E;&5M96YT87)Y('-T<F5A;2!F;W(@=&AE M(&9R965Z92!P:6-T=7)E(')E;&5A<V4@8V]N=')O;"!C;VUM86YD.PU7:&5N M(&EN8V]M:6YG('9I9&5O('1O($$@8VAA;F=E<R!F<F]M($(M<&EC='5R92!T M;R!#+7!I8W1U<F4L('9I9&5O(&1E8V]D:6YG('!R;V-E<W,@;6%Y(&)E(&1I M<W)U<'1E9&9R86UE(&%L:6=N;65N="!I<R!L;W-T+"!A;F0@=VEL;"!T86ME M(&$@=&EM92!4('1O(')E8V]V97(L(&1E<&5N9&5N="!O;B!T:&4@=FED96\@ M8FET(')A=&4@86YD(&]T:&5R(&9A8W1O<G,[#4%F=&5R(&$@=&EM92!G<F5A M=&5R('1H86X@5"P@=&AE($U#52!T<F%N<VUI=',@=FED96]&87-T57!D871E M4&EC='5R92!T;R!T97)M:6YA;"!#.PU/;B!R96-E:7!T(&]F('9I9&5O1F%S M=%5P9&%T95!I8W1U<F4L('1E<FUI;F%L($,@<V5N9',@:71S(&YE>'0@=FED M96\@9G)A;64@:6X@DV9A<W0M=7!D871EE"!M;V1E+"!T;V=E=&AE<B!W:71H M('1H92!(+C,Q,"!6:61E;RU&<F%M92U3>6YC:')O;F]U<R!#)DD@=FED96]& M<F5E>F50:6-T=7)E4F5L96%S94-O;G1R;VP@<VEG;F%L8V]M;6%N9#L-3VX@ M<F5C96EP="!O9B!T:&4@1G)E97IE(%!I8W1U<F4@4F5L96%S92!S:6=N86QC M;VUM86YD+"!T97)M:6YA;"!!(')E=F5R=',@=&\@9&ES<&QA>6EN9R!T:&4@ M:6YC;VUI;F<@9&5C;V1E9"!P:6-T=7)E+@T-6"XU"4UO9&4@<W=I=&-H:6YG M(&%N9"!D871A(&)R;V%D8V%S="!P<F]C961U<F5S#0U8+C4N,0E":70M<F%T M92!S>6UM971R>0T-26X@82!P;VEN="UT;RUP;VEN="!C86QL+"!A;B!(+C,Q M,"!T97)M:6YA;"!C86X@<F5Q=65S="!A(&YE=R!M;V1E(&]F(&%U9&EO=FES M=6%L(&-O;6UU;FEC871I;VX@;W9E<B!T:&4@9&EF9F5R96YT(&QO9VEC86P@ M8VAA;FYE;',@=7-I;F<@=&AE(&UO9&4@<F5Q=65S="!S:6=N86QI;F<@<')O M=&]C;VP@9&5F:6YE9"!I;B!(+C(T-2!A<R!D97-C<FEB960@:6X@4V5C=&EO M;B X+CDV+C0N-"P@86YD(&-A;B!S=VET8V@@=&\@82!N97<@;6]D92!U<VEN M9R!T:&4@;&]G:6-A;"!C:&%N;F5L('-I9VYA;&EN9R!P<F]T;V-O;"!A;F0@ M8FDM9&ER96-T:6]N86P@;&]G:6-A;"!C:&%N;F5L('-I9VYA;&EN9R!P<F]T M;V-O;"P@86YD(&%I9&5D(&)Y('1H92!C;&]S92!L;V=I8V%L(&-H86YN96P@ M<VEG;F%L:6YG('!R;W1O8V]L+"!D969I;F5D(&EN($@N,C0U(&%S(&1E<V-R M:6)E9"!I;B!396-T:6]N<R X+C0M."XV-BXT+C,N("!(;W=E=F5R+"!I;B!A M(&UU;'1I<&]I;G0@8V%L;"P@=&AE<F4@87)E(&%D9&ET:6]N86P@=&5M<&]R M86P@8V]N<W1R86EN=',Z#0UB96-A=7-E('1H92!O=71P=70@<&%C:V5T<R!F M<F]M('1H92!-0U4@8V%N;F]T(&)E('-Y;F-H<F]N;W5S('=I=&@@86QL(&EN M<'5T('!A8VME=',L('1H97)E('=I;&P@=7-U86QL>2!B92!A="!L96%S="!S M;VUE(&1E;&%Y(&EN('1R86YS;6ET=&EN9R!A(&YE8V5S<V%R>2!C;VUM86YD M(&-O9&4[(&EN(&$@;6]R92!E>'1R96UE(&-A<V4@=&AE($U#52!M87D@86QR M96%D>2!B92!E;F=A9V5D(&EN(&$@8V%P86)I;&ET>6-A<&%C:71Y(&5X8VAA M;F=E('=I=&@@86YO=&AE<B!T97)M:6YA;"P@86YD('-O(&)E('5N86)L92!I M='-E;&8@=&\@;6]D92!S=VET8V@@9F]R('-O;64@=&EM93L-=&EM92!I<R!N M965D960@9F]R('1H92!-0U4@=&\@<')O8V5S<R!C87!A8FEL:71Y(&-O9&5S M(&%N9"!C;VUM86YD<R!T;R!E;G-U<F4@=&AA="!T:&4@<F5S=6QT:6YG(&UO M9&5S(&%R92!A8V-E<'1A8FQE('1O(&%L;"!T97)M:6YA;',@86YD(&%R92!I M;7!O<V5D(&EN(&-O;W)D:6YA=&EO;BP@=VET:&]U="!C;W)R=7!T:6]N(&]F M(&%N>2!V:61E;R!B96EN9R!T<F%N<VUI='1E9"X-#51O(&5N<W5R92!T:&%T M(&%N($U#52!H87,@861E<75A=&4@8V]N=')O;"P@86YD(&EN('!A<G1I8W5L M87(@=&AA="!I="!C86X@9')I=F4@=FED96\@<VEG;F%L('1R86YS;6ES<VEO M;B!T;R!A(&-O;6UO;B!R871E("AN;W1I;F<@=&AA="!I;B!T:&4@8V%S92!T M<F5A=&5D(&AE<F4@=&AE($U#52!H87,@;F\@<&]W97(@=&\@=')A;G-C;V1E M('1H92!V:61E;RDL(&)I="UR871E(&-H86YG97,@<VAA;&P@8F5A<F4@:6YI M=&EA=&5D('-O;&5L>2!F<F]M('1H92!-0U4N(%1E<FUI;F%L<RP@869T97(@ M:&%V:6YG(')E8V5I=F5D(&UU;'1I<&]I;G1#;VYF97)E;F-E(&9R;VT@34-5 M+"!S:&%L;"!N;W0@8VAA;F=E(&)I="UR871E(&5X8V5P="!I;B!R97-P;VYS M92!T;R!S=6-H(&$@8VAA;F=E(&EN8V]M:6YG(&9R;VT@=&AE($U#52X@34-5 M(&UA>2!C:&]O<V4@=&\@<V5N9"!(+C(T-2!&;&]W0V]N=')O;$-O;6UA;F0@ M=&\@86-H:65V92!T:&4@8FET+7)A=&4@<WEM;65T<GDN(%1H:7,@87!P;&EE M<R!T;R!B:70M<F%T97,@9F]R(&%U9&EO+"!D871A+"!V:61E;RP@86YD('1H M92!T<F%N<V9E<B!R871E.R!A=61I;R!A;F0@=FED96\@;6]D92!C:&%N9V5S M(&YO="!I;G9O;'9I;F<@8FET+7)A=&4@8VAA;F=E<R!M87D@<W1I;&P@8F4@ M:6YI=&EA=&5D(&)Y('1E<FUI;F%L<RX@5VAE;B!T:&4@8FET(')A=&4@:6YC M;VUI;F<@9G)O;2!-0U4@8VAA;F=E<RP@=&AE('1E<FUI;F%L<R!S:&%L;"!F M;VQL;W<@<W5I="!A<R!P<F]M<'1L>2!A<R!O=&AE<B!P<F]C961U<F5S(&%L M;&]W+"!A<R!A;GD@9&5L87D@;6%Y('!R96-L=61E('1H92!T97)M:6YA;))S M('1R86YS;6ES<VEO;B!F<F]M(&)E:6YG(')E8V5I=F5D(&)Y('1H92!O=&AE M<B!P87)T:65S(&EN(&$@8V]N9F5R96YC92X-#5@N-2XR"4UO9&4@<W=I=&-H M:6YG(&9O<B!D871A(&1I<W1R:6)U=&EO;B!I;B!M=6QT:7!O:6YT(&-O;F9E M<F5N8V5S#0U5;F1E<B!W;W)K:6YG+@T-6"XV"4U#52U-0U4@26YT97)C;VYN M96-T:6]N<PT-56YD97(@=V]R:VEN9RX-#5@N-PE%>&-E<'1I;VYA;"!P<F]C M961U<F5S#0U5;F1E<B!W;W)K:6YG+@T-#5DN"4%D=F%N8V5D(&-O;6UU;FEC M871I;VX@<')O8V5D=7)E<R!U<VEN9R!4+C$R,"]4+C$S,"!C;VYT<F]L<PT- M1F]R(&9U<G1H97(@<W1U9'DN#0T-+2TM+2TM+2TM+2TM+2TM+2TM/"!/:W5B M;]5S(&YO=&5S(#XM+2TM+2TM+2TM+2TM+2TM+2T-#3$N"5-I;7!L92!E9&ET M;W)I86P@8V]R<F5C=&EO;G,L('-U8V@@87,@<W5B:F5C="UV97)B(&-O<G)E M<W!O;F1E;F-E+"!H879E(&)E96X@;6%D92!W:71H;W5T(&-H86YG92!M87)K M<PT-,BX)06YO=&AE<B!C;VUM=6YI8V%T:6]N('!R;V-E9'5R92!S96-T:6]N M(&9O<B!V:61E;R!M:7AI;F<_(%!E<FAA<',@;F]T+B!792!C86X@96%S:6QY M(&5X=&5N9"!396-T:6]N(%@@=&\@8V]V97(@=FED96\@;6EX:6YG(&9R;VT@ M=&AE('!R;V-E9'5R92!P97)S<&5C=&EV92X@270@=V]U;&0@8F4@8F5T=&5R M('1O(&%D9')E<W,@8F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S('=I M=&@@86YD('=I=&AO=70@=FED96\@;6EX:6YG+"!B=70@=7-I;F<@2"XR-#4@ M86YD($@N,S$P(&-O;G1R;VQS+@T-,RX)06YO=&AE<B!C;VUM=6YI8V%T:6]N M('!R;V-E9'5R92!S96-T:6]N(&9O<B!P;VEN="UT;RUM=6QT:7!O:6YT(&-O M;F9I9W5R871I;VX_#0TT+@E!9&0@=&AE(&9O;&QO=VEN9R!D969I;FET:6]N M<SH-#7-E;&5C=&5D(&-O;6UU;FEC871I;VX@;6]D92 H4T--*3H@82!C;VUM M=6YI8V%T:6]N(&UO9&4@=VAI8V@@34-5(&ED96YT:69I97,@=&\@=7-E(&EN M(&$@<&%R=&EC=6QA<B!M=6QT:7!O:6YT(&-O;6UU;FEC871I;VX@<V5S<VEO M;BX@4V5E($@N,C0S+@T-<')I;6%R>2!T97)M:6YA;#H@82!T97)M:6YA;"!W M:&EC:"!S=7!P;W)T<R!T:&4@4T--+B!3964@2"XR-#,N#0US96-O;F1A<GD@ M=&5R;6EN86PZ(&$@=&5R;6EN86P@=VAI8V@@9&]E<R!N;W0@<W5P<&]R="!T M:&4@4T--+B!3964@2"XR-#,N#0TU+@E);B"D6"XT8RDL($D@:&%V92!C:&%N M9V5D(-)F<F%M92!A;&EG;FUE;G0@:7,@;&]S=-,@=&\@TG9I9&5O(&1E8V]D M:6YG('!R;V-E<W,@;6%Y(&)E(&1I<W)U<'1E9-,@8F5C875S92!F<F%M92!A M;&EG;FUE;G0@;6%Y(&EM<&QY('1H870@;V8@2"XR,C$N(%1H97)E(&ES(&YO M(&-O<G)E<W!O;F1I;F<@TF9R86UETR!I;B!(+C(R,BXQ+S N#0TV+@E);B!T M:&4@8FET(')A=&4@<WEM;65T<GD@9&5S8W)I<'1I;VX@:6X@I%@N-2XQ+"#2 M34-5(&UA>2!C:&]O<V4@=&\@<V5N9"!(+C(T-2!&;&]W0V]N=')O;$-O;6UA M;F0@=&\@86-H:65V92!T:&4@8FET+7)A=&4@<WEM;65T<GDNTR!H87,@8F5E M;B!S=&%T960@86-C;W)D:6YG('1O('1H92!D:7-C=7-S:6]N(&EN(%-U;G)I M=F5R("AS964@I#0N,RXR+T%00RTQ,S(W*2X@5&AI<R!I<R!B87-E9"!O;B!M M>2!U;F1E<G-T86YD:6YG('1H870@875D:6\L('9I9&5O(&%N9"!D871A(')A M=&5S(&-A;B!B92!C;VYT<F]L;&5D(&5I=&AE<B!B>2!(+C(T-2!&;&]W0V]N M=')O;$-O;6UA;F0@;W(@4F5Q=65S=$UO9&4N($AO=V5V97(L('1H92!T<F%N M<V9E<B!R871E(&-A;B!O;FQY(&)E(&-O;G1R;VQL960@8GD@2"XR-#4@1FQO M=T-O;G1R;VQ#;VUM86YD+B!)<R!M>2!U;F1E<G-T86YD:6YG(&-O<G)E8W0_ M#0T-14Y$#0T-&@". )SA IWA J2%+J7"0::*!:>*!:BY ZF;!'P @ P M $@ 2 #+@(Z__+_\@,\ D4#1P5[ ^ @ $@ 2 "V (H $ M !D 0 # P, _P !)P\ 0 ! 8 @ &0&0 M 0 #0SQ'@H;$:X0 M .P #__X "0 & $ ! $ " M ?____X /______________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________!0!3 '4 ;0!M &$ M<@!Y $D ;@!F &\ <@!M &$ = !I &\ ;@ M "@ @#_______________\ M " [0$ M M /_______________P M M ____ M____________ M M #_____________ M__\ M # +T!0 " =M/RS.<!0 #$BAP# +T! P # M $ !X 3 36EC<F]S;V9T(%=O<F0@-BXP , M '@ ( R , /__@ ) 8 M '____^ #_________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________P # " P -0, #8# W P .P, M $(# !# P M@, %($ !3! 500 ,T$ #1! V00 .P$ 9!0 M5P4 '<% "N!0 M 4 *D& "J!@ A < (4' #@" X0@ &\) "% M"0 U@D .$) ="@ 'PH $(* !'"@ I@H *<* "M"@ ^0H /X* M E"P 3 L )0+ "9"P \@L /4+ ]#0 2 T $L- ###0 S@T M -$- "3#@ E X ,\. #0#@ UPX -@. 2#P 20\ %4/ !I#P M;@\ ( / #&$ R1 ,X1 #4$0 YA$ /@1 #[$0 /!( #T2 _ M$@ 01( /[W_@#^\/X [0#M /[I_NGM .WC[0#MZ>WI[>GMZ>T [0#I[0#M MW>W8[>GM .W2RNW$O.T [0#M .W8[>GMZ>T [0#MZ?[M .T .08%% 0!& M0!0<1DD! "D*!10$ 1D 4'$8 #D&!10$ 1CL4'$9) 0 I"@44! $8[ M%!Q& A6@5X!20$ *0H%% 0!&FA0<1@ *0H%% 0!&'Q0<1@ &58%) 0 M 1) 0 Q"@44! $8>%!Q&58$ #$*!10$ 1AT4'$95@0 "58%*01( %82 M !A$@ 9Q( '$2 ",$@ C1( ) 2 #G$@ #A0 " 4 \% /10 M ($4 ""% IQ4 *@5 #>%0 WQ4 &46 !F%@ :Q8 &P6 !R%@ MB!8 )T7 "A%P R!< .\7 !& A@ "H8 O& 8Q@ )D8 "E M& N1@ ,0: #*&@ W!H .X: #Q&@ ,QL #0; V&P .!L $T; M !8&P 8AL &H; "%&P AAL (D; #2&P S1P -\< #[' _!P M $ = !!'0 )!X "4> !;'@ 7!X *L> "L'@ Q\ !L? G'P M.A\ -L? #C'P [A\ 0@ #!( UR #,A T(0 _?G]\_WS_>[] M^?T _0#] /T _0#] /WY_0#][OT _>C][OWY_0#]^>;] /T _?G]X/W@_>[] M^?T _0#] /T _0#]^?W8_=+]^?WY_<P "D*! M10$ 1KL4'$8 "D*!10$ 1K<4'$8 #D&!10$ 1IL4'$9) 0 I"@44! $:5 M%!Q& )5@0 *0H%% 0!&FQ0<1@ (5H%> 4D! "D*!10$ 1EP4'$8 !E6! M20$ $20$ $TT(0 -2$ #DA !5(0 ?R$ ),A ":(0 FR$ &\B M !Q(@ <B( '4B "9(@ P"( -,B #4(@ '2, "(C G(P ,R, M &DC !U(P B2, )(E "8)0 JB4 +PE "_)0 "8 $F #)@ M!28 !HF E)@ +R8 #<F !2)@ 4R8 %8F "+)@ A2< )<G #W M)P ^"< -HH #;* $2D !(I !B*0 8RD +XJ #"*@ )"L "@K M I*P *BL )LK "?*P H"L *$K O+ 02P #DM !*+0 \2T M /4M &+@ N"X +DN #,+@ WRX !\O X+P ^/+JY-[; -L VP#; MUML V]#(V];;Q-L V\3"VP#; -O$V[S;O-O6V\3; -L VP#; -L VP#; -L MVP#;Q-O$V\+$VP#;Q-NV"D*!10$ 1B$;'&8 "D*!10$ 1L44'$8 E6! 95 M@4D! #D&!10( 1L 4'$9) 0 I"@44! $; %!Q& A6@5X!20$ $ M20$ *0H%% 0!&NQ0<1@ *0H%% 0!&NA0<1@ .0H%% 0!&NA0<1DD! M"D*!10$ 1KD4'$8 #D&!10$ 1KL4'$9) 0 2#@O ""+P E2\ )8P "< M, O3 -0P !;,0 <3$ (\Q "E,0 ]3$ !,R 4,@ &#( #@R M Y,@ /S( $8R !Q,@ =S( 'XR "_,@ P#( ,HR #3,@ YC( M / R #Q,@ \C( /@R F,P )S, ,HS #7,P XC, .4S #J,P MN30 ,DT #0- T30 -(T #9- WC0 "HU K-0 $38 !LV C M-@ -C@ #XX !!. @C@ )8X #]^?WS[>7]^?WY_=_]W_G]V=']V='] M ,_YR,'Y_0#] /VY_;.Y_;G]K?VMI?T _9^7_9&)_?D.08%% 0!&D1L<9DD! M "D*!10$ 1I$;'&8 #D&!10$ 1HL;'&9) 0 I"@44! $:+&QQF Y! M@44! $9@&QQF20$ *0H%% 0!&8!L<9@ *0H%% 0!&7QL<9@ .08%% 0!& M7QL<9DD! #$*!10$ 1DD;'&95@0 ,0H%% 0!&2!L<9E6! )5@0 .08%% M 0!&-!L<9DD! "D*!10$ 1C0;'&8 "D*!10$ 1C,;'&8 #D&!10$ 1H@; M'&9) 0 I"@44! $:(&QQF I"@44! $:*&QQF 95@4D! !$D! V MEC@ /8X 3.0 )3D $@Y #6.@ USH -TZ K.P +#L "T[ Q M.P 2CL $L[ !9.P 6SL %\[ !U.P A3L (@[ #5.P VCL -P[ M 6/@ -SX *@^ "X/@ Z3X /L^ !+0 74 #5! !'00 2T$ M %9! "300 I4$ ,I! #+00 S$$ &1" #]]_#W_0#JY #]XMX _0#B MWOT V-+8 .( X@#B .( X@#> .( #0 M M M M M "=0$ "D*!10$ 1NT;'&8 "D*!10$ 1C44'$8 !E6!20$ M "58$ "D*!10$ 1ED;'&8 "D*!10$ 1DH;'&8 #$*!10$ 1LD;'&95@0 * M0H%% 0!&R1L<9@ $20$ "@ P -@, #<# !# P 1 , ,P$ #-! M& 4 !D% !P!@ <08 *H& "K!@ \P8 (4' #A" ,@D #,) !" M"@ 0PH *8* "G"@ _@ /X #^ _@ /X M #^ X0 .$ #A X0 .$ M #A P , # P /X #^ M _@ *, "& M ' ##0 (X @ " !0 0!H 0 "X@ M !P PT ". ( @ 4 ( M: $ N( @ - M"A%H 1.8_@PT ". ( @ 4 $ : $ I( M < ,- 0@ /__ ! &@! +@ M 0 %:<* #0"@ T0H M "0+ E"P 30L $X+ !S#@ = X !$/ 2#P 2@\ $L/ #6$0 MUQ$ (\2 "0$@ Z!( .D2 #^%0 _Q4 &P6 !M%@ L!8 .L6 #C M Q@ ,8 #& Q@ ,8 #& M Q@ ,8 #& Q@ ,8 #& MQ@ ,8 "H Q@ *@ #& Q@ M ,8 #& AP (< " T+$6@!$YC^ M##3_ 0 ( ! 0!H 0 +< M !T T,##3_ 0 ( ! 0!H 0 +< M !P PT_P$ " 0 $ : $ M "W < ,- " M 3@" ( % ! &@! ,BX@ M 8ZQ8 .P6 !"%P 0Q< )P7 "=%P QQ< ,@7 #P%P \1< M &(8 !C& FA@ )L8 #,&@ S1H (@; ")&P TQL -0; "Q'0 MLAT *P> "M'@ XP ., #C XP ., M #& J ., #C XP ., #C M B@ ., #C XP ., #C M B@ ., #C %X(_ XP #>"/P ., 7@C\ M '0 #0P,-/\! @ $ ! &@! MP M '0 #0P,- " 3@" ( % " M &@! ,BX@ ' M##0 @$X @ " !0 @!H 0 #(N( M !P PT_P$ " 0 $ : $ "W M !>M'@ M1X #X? "C'P JQ\ (@@ M V(0 E"$ )LA #U(0 ;B( &\B "8(@ F2( -\ "^ M O@ ">"/P -\ "^ O@ #>"/P +X G@C\ #? MO@ +X G@C\ "A A &< M M !P PT (!. ( @ 4 $ : $ R+B M < ,- " 3@" ( % " &@! ,BX@ M ' ##3_ 0 X @ # !0 M 0!H 0 &X " M T+$6X$$U?^##3_ 0 X @ # !0 0!H 0 &X M " T+$6@!$YC^##3_ 0 ( ! 0!H M 0 +< #9DB #! M(@ PB( #(C S(P :B, &LC ":)0 FR4 %4F !6)@ BR8 (PF M !G* :"@ &,I !D*0 ;"D *HI #C XP !>"/P ., G@C M\ #C %X(_ XP !>"/P ,4 #C XP !>"/P ., W@C\ "H M XP ,4 #C XP !>"/P ., W@C\ #C %X M(_ AP &8 " T+$6X$$U?^##3_ 0 X @ # !0 0!H M 0 &X " T+ M$6@!$YC^##3_ 0 ( ! 0!H 0 +< M !P PT (!. ( @ 4 $ : $ R+B M = -# PT_P$ " 0 M $ : $ "W < M ,-/\! @ $ ! &@! MP M 2JBD !<J ?*@ Q"H ,HJ C*P )"L %HK !; M*P FBL -\ "^ WP +X #? H0 M (0 !G 2@ M !P PT (!. ( @ 4 $ : $ M R+B < ,- " M 3@" ( % ! &@! ,RX@ M ' ##0 @$X @ " !0 ! !H 0 #,N( M !P PT_P$ . ( P 4 $ : $ !N M @ -"Q%H 1.8_@PT M_P$ " 0 $ : $ "W M @ -"Q%N!!-7_@PT_P$ . ( P 4 $ : $ !N M F:*P FRL +<K "X*P M["P (0M #P+0 \2T 8N '+@ N2X +HN #C Q@ M *D "I 1X(_ B (@$_W@C, *I :P $X M !. )X(_ 3@ !>"/P M < ,- $ 3@" ( % ! &@! -"XQ+B M ' ##0 (X @ " !0 P!H 0 "X@ M " T+$6@!$YC^##3_ M 0 ( ! 0!H 0 +< M !P PT (!. ( @ 4 $ : $ R+B M < ,- " 3@" ( % & &@! M,BX@ ' ##0 ! $X @ " M !0 0!H 0 #(N-2X@ M"[HN !O+P 6# "PQ "!,0 2#( +\R # ,@ \3( /(R *,P M"S, "LU L-0 >C8 %4W !6-P UCH -<Z #? WP #>"/P M -\ W@C\ #? %X(_ WP #>"/P -\ G@C\ #= P *, M #= A@ (8 !G@C\ "& %X(_ WP -\ W@C M\ !I :0 *>"/P &D 7@C\ !P PT! !" 8 M $ : $ I < M ,- " 3@" ( % ! &@! -2X@ M ' ##0 (X @ " !0 0!H 0 "X@ M !P PT ". H @ 4 4 : $ M N( ! ( M#0H1: $3F/X,- 0 0@ & ! &@! *0 M 2USH !P[ =.P +#L "T[ !*.P 2SL M %H[ !;.P =CL '<[ "&.P ASL (@[ #(.P R3L -P[ #=.P MWCL !0\ 5/ ?SP ( \ "?/0 H#T /(] #S/0 %3X !8^ "G M/@ J#X .@^ #I/@ ,S\ #0_ #C XP !>"/P ., 7@C\ #C M %X(_ Q@ ,0 #$ %X(_ Q !>"/P ., 7@C\ #C %X M(_ Q ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ MQ !>"/P ,0 7@C\ #! %X(_ Q ,0 G@C\ #$ %X(_ Q $ M>"/P ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ Q ">"/P M ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ " M % 0 ! ' ##0 @$X @ " !0 !0!H 0 #,N( M !P PT! !" 8 $ : $ M I "(T/P ^3\ /H_ M #$00 Q4$ ,9! #*00 RT$ ,Q! #^ -X(_ _@ !>"/P /X !G@C M\ #^ %X(_ _@ !>"/P /X 7@C\ #^ _@ !>"/P M M M M M M M M M M 0 " X $0 ( $ 2P / ! < ! \?\" !P !DYO<FUA; " M!@!A"01C& B $% \O^A "( %D1E9F%U;'0@ M4&%R86=R87!H($9O;G0 #P 'F ! /( / /06YN;W1A=&EO M;B!497AT 7 \ !0,5B /#@ $&@.G!#0&P0< 8 70 8Q0 .@#^ M;P$ @$Z AE;G5M;&5V,0 = ! !0,1IP03<_X55@ /#@ $&@.G!#0&P0< M 8 70 8Q0 S#X # ,P^ ' ,Q! ' .A! & M 0!__\! __\" 0 __\# __\$ 0 __\% __\& A#@ ML1H &0F L,@ ^3P ,P^ +4 ! $ " @ # $X! $ M $ % P 01( #0A X+P EC@ &1" B ", ) E "8 M , *<* #K%@ K1X )DB "J*0 FBL +HN #7.@ -#\ ,Q! G M "@ *0 J "L + M "X +P P #8 !U5N:VYO=VX =A:V%S86MA 0 =075T M:&]R:7IE9"!5<V5R =5;FMN;W=N % , !$ @=A:V%S86MA.TUA M8VEN=&]S:"!(1#I$97-K=&]P($9O;&1E<CI7;W)K(&9O;&1E<CI396-T:6]N M(%@@;V8@2"YB;7!T!V%K87-A:V$R36%C:6YT;W-H($A$.E1E;7!O<F%R>2!) M=&5M<SI7;W)D(%=O<FL@1FEL92!!(#$S-C8'86MA<V%K83)-86-I;G1O<V@@ M2$0Z5&5M<&]R87)Y($ET96US.E=O<F0@5V]R:R!&:6QE($$@,3,V-@=A:V%S M86MA,DUA8VEN=&]S:"!(1#I496UP;W)A<GD@271E;7,Z5V]R9"!7;W)K($9I M;&4@02 Q,S8V!V%K87-A:V$R36%C:6YT;W-H($A$.E1E;7!O<F%R>2!)=&5M M<SI7;W)D(%=O<FL@1FEL92!!(#$S-C8'86MA<V%K83M-86-I;G1O<V@@2$0Z M1&5S:W1O<"!&;VQD97(Z5V]R:R!F;VQD97(Z4V5C=&EO;B!8(&]F($@N8FUP M= =A:V%S86MA.TUA8VEN=&]S:"!(1#I$97-K=&]P($9O;&1E<CI7;W)K(&9O M;&1E<CI396-T:6]N(%@@;V8@2"YB;7!T!V%K87-A:V$:4D%-((-F@T*#6(-. M.E-E8W1I;VY?6"YD;V,'86MA<V%K83M-86-I;G1O<V@@2$0Z1&5S:W1O<"!& M;VQD97(Z5V]R:R!F;VQD97(Z4V5C=&EO;B!8(&]F($@N8FUP= =A:V%S86MA M&E)!32"#9H-"@UB#3CI396-T:6]N7U@N9&]C_T #@ $ %3D !4Y ' $ M 5.0 !4Y ! /__?0-W DT %0:0 4T 5&EM97,@3F5W(%)O;6%N M P&D $" %-Y;6)O; +!I !30!!<FEA; /!I ! @!7:6YG9&EN9W, "P:0 M 4T 5&EM97, (@ $ #$(C!@ - " !H 0 #R&QQF\AL<9@ " M 0 @Q M *0E %@ V6"X)0F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S M('5S:6YG($@N,C0U(&-O;G1R;VQS !V%K87-A:V$'86MA<V%K80 M #0SQ'@H;$:X0 .P #__X "0 & M $ ! $ " ?____X /______ M____________________________________________________________ -____________________ end

1 0

GCL ftp site has got back to operation
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Q.12-14/16 experts, GCL ftp site (ftp://itu-t:sg15!avc@ftp.gctech.co.jp) has been restored; it is now accessible. Please Mr. Webber resume your mirroring. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0

Issues related to H.225.0 and H.450
by Orit Levin 03 Dec '97

03 Dec '97

Karl and Editors! I agree with your point #2 (H.450.2 Clause 10.6.1.1). My only request is to expand the OPTIONAL possibilities of the FACILITY message NOW. H.450.x are new evolving, and therefore flexible, series. On the other hand, who knows when H.323v3 will be available! Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516 ---------- From: Karl Klaghofer [SMTP:karl.klaghofer@MCH.PN.SIEMENS.DE] Sent: Wednesday, December 03, 1997 4:41 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData and other issues related toH.450 Some comments related to H.450.x have been placed to the reflector the last days. 1) H.450.2 Clause 10.5 (item 1 of Levin Orit´s comments, dated Dec.1) I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... should be deleted. 2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit´s comments, dated Dec.1) The procedures defined for this gatekeeper active transfer case right now are very much based on the gatekeeper having H.225 as well as H.245 control (i.e. H.225 as well as H.245 routed via gk). The model you are referring to (H.225 via gk; H.245 direct routed) was not investigated in conjunction with active gk transfer, since this model is (as Pete sayd) still marked as "for further study" in H.323V2 ! Using the direct H.245 model in conjunction with active transfer by gatekeeper would introduce a further, alternative method of handling the logical channel closing and reopening issue at the transferred endpoint B. Remark: In Sunriver September meeting, the goal was to have just one method (we picked the "empty terminalCapabilitySet" method and dropped the "requestChannelClose with reopen" method in order to reach this goal. Proposal for further proceeding: First the H.245 direct model has to be investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might be updated to get this model also to work for active gk transfer. 3) Limitation of nonStandardData (Comment from Pete Cordell, dated Dec.2) Currently we have in H.450.x constructs like the following: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} ExtensionSet EXTENSION ::= {...} -- Actual values defined by individual manufacturers This means: either one value nonStandardParameter or a SEQ of an arbitrary number of values of type Extension may be inserted. 1st possible change: allow more than one nonStandardParameter: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData SEQUENCE OF NonStandardParameter } OPTIONAL which means either a SEQ of Extensions or a SEQ of NonStandardParameter may be inserted. This 1st possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245. 2nd possible change: argumentExtension SEQUENCE OF MixedExtension OPTIONAL MixedExtension ::= CHOICE {extension Extension{{ExtensionSet}}, nonStandardData NonStandardParameter } This 2nd possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245, which adds a further dimension of allowing mixing of any number of NonStandardParameter and ISO like Extensions within one pdu. This may have advantages e.g. in the case that an ISO like Extension is contained within a received pdu in a gk and the gk wants to add further extensions of the NonStandardParamter type (or vice versa) to the same pdu. Proposal for further proceeding. The 2nd possibility mentioned above should be added to a H.450V2. ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ==================================================

1 0

FW: Remarks on H.450.x and H.225.0
by Orit Levin 02 Dec '97

02 Dec '97

Dear Pete and all others ! My additional comments are below: >3. H.225.0 Annex H - ASN.1 >All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. ------------------------------------------------------------------------------------- We agree with Pete's proposal. It is more general but requires more changes in the standard. Let fix it one way or another, but till Geneva! ------------------------------------------------------------------------------------- > >4. H.450.2 Clause 10.6.1.1 >This clause is talking about Call Transferring in case of GK Call >Routed model and both Q.931 Signaling and H.245 protocol are "routed" >by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >Signaling is routed by the GK, but H.245 messages flow directly is >legal and more efficient. It seems that the clause above doesn't cover >this case. In order to provide a working solution for this case, an >additional OPTIOANAL field "h245Address" should be added to >Facility-UUIE message ... ------------------------------------------------------------------------------------- Three things on this: Firstly, Pete, you are right about the "future study". Still this mode is more efficient and we shouldn't cancel it without serious considerations. In this case (of H.450.2) with this optional field we could support it. Do we want to cancel the possibility of using this mode without even studying it ? Secondly, the facility message, described in H.450.2 section, may contain Facility-UUIE as a part of it. Currently this Facility-UUIE is empty, but it can be used and have a new h245Address field. Thirdly, I will try to explain the relevant scenario using H.450.2 terminology. Suppose, A and B are in the GK routed call, while H.245 and UDP streams flow directly between them. All "transferring logic" is performed by the GK on behalf of B. None of the mentioned messages (specifically CONNECT message) reaches B. Still, when the call is transferred from A to C, B has to receive (a new) H.245 address of C. The proposed way to receive it, is by means of FACILITY message containing Facility-UUIE. Pay attention that B, who doesn't perform the "transferring logic" itself, upon arrival of the FACILITY message containing a new H.245 address, has to close the old H.245 channel and open a new one (towards C). ------------------------------------------------------------------------------------- (I am starting to enjoy it, but I am serious.) >>Thanks, > >Orit Levin >RADVision Inc. E Mail: orit(a)radvision.com >575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 >Mahwah, NJ 07430 Fax: 201-529-3516 >

1 0

Re: Limitation of nonStandardData
by Scott Petrack 02 Dec '97

02 Dec '97

This problem has bothered me for a long time. I considered many times introducing into the VoIP Forum an OID which would be used precisely as Jim suggests, so that the entire industry could signal a SEQUENCE of NonStandardParameter. One example of why this is necessary is so that when someone else uses our stack we can both pass non-standard parameters. Question to all "industry techie-leaders" (by definition people reading this message ;-)). Is there any chance of gettting agreement on this or is it too late? Of course we can do it privately (and we do), but it would be very useful to have everyone do it together, no? I would offer an OID in the VoIP forum's space, but I really could not care less about ownership. If there is a way to put this into the standard, that would be fantastic. Scott jtoga(a)ideal.jf.intel.com on 12/01/97 09:42:53 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: Limitation of nonStandardData Pete, An easy fix for backward compatability is to simply define a particular 'nonStandardParameter' as a "SEQUENCE OF nonStandardParameter". Regards, jimt. At 07:02 PM 12/1/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

2 1

Re: Limitation of nonStandardData
by Douglas Clowes 02 Dec '97

02 Dec '97

I had also noted this potential limitation. While the 'SEQUENCE OF' is ther nicest fix for it, an alternative possibility is to wrap (encapsulate) the original nonStandardData in the new one (as part of the data) and unwrap it later. This would work where the message path is EP-GK-GK-EP and the EP's are exchanging nonStandardData plus the GK's are also. Douglas At 19:02 1/12/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > >

1 0

Re: Limitation of nonStandardData
by Jim Toga 01 Dec '97

01 Dec '97

Pete, An easy fix for backward compatability is to simply define a particular 'nonStandardParameter' as a "SEQUENCE OF nonStandardParameter". Regards, jimt. At 07:02 PM 12/1/97 -0000, you wrote: >Dear All, > >I have noticed that there is a limitation in H.225 (and H.245) on how >nonStandardData is included in messages. Basically only one >non-standard element can be included in each PDU. This is because of >the syntax: > > nonStandardData NonStandardParameter, > >What is really required for a truly extensible protocol is: > > nonStandardData SEQUENCE OF NonStandardParameter, > >This is especially important if a gatekeeper wants to insert >nonStandardData into a message that already has nonStandardData added in >to it by an endpoint. > >This may be too late to fix for H.225, but we can fix this for the >H.450.x protocols. > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Limitation of nonStandardData
by Pete Cordell 01 Dec '97

01 Dec '97

Dear All, I have noticed that there is a limitation in H.225 (and H.245) on how nonStandardData is included in messages. Basically only one non-standard element can be included in each PDU. This is because of the syntax: nonStandardData NonStandardParameter, What is really required for a truly extensible protocol is: nonStandardData SEQUENCE OF NonStandardParameter, This is especially important if a gatekeeper wants to insert nonStandardData into a message that already has nonStandardData added in to it by an endpoint. This may be too late to fix for H.225, but we can fix this for the H.450.x protocols. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: Remarks on H.450.x and H.225.0
by Pete Cordell 01 Dec '97

01 Dec '97

Dear All, Please see comments below: Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Orit Levin[SMTP:orit@RADVISION.COM] >Sent: 01 December 1997 15:59 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Remarks on H.450.x and H.225.0 > >Hello, Editors! > >We are working know on the Supplementary Services stuff and came across >some pitfalls in the last (Geneva) versions of the above protocols. It >would be helpful to fix them before Geneva. I am listing them below: > >1. H.450.2 Clause 10.5 ><<FACILITY message containing a callTransferInitiate invoke APDU and >conferenceGoal = "invite">> is mentioned here. There is no >conferenceGoal in FACILITY message. Possibly this mistake derives from >the SETUP message, mentioned later in the same clause, which indeed has >conferenceGoal field. > >2. H.225.0 Annex H - ASN.1 >InfoRequestResponse ::= SEQUENCE --(IRR) >{ > nonStandardData NonStandardParameter OPTIONAL, > . > . > perCallInfo SEQUENCE OF SEQUENCE > { > . > . > originator BOOLEAN, > . > . > } OPTIONAL, > ..., > . > . >} > >The field "originator" is no longer OPTIONAL (the way it was defined in >V.1), which makes the situation NOT backward compatible. Was there any >reason for that change, or it just a mistake? In any case, because of >the ASN.1 encoding rules, this situation highly undesirable. This looks correct. I'm partly responsible for this as I asked Glen to take out OPTIONAL from a number of BOOLEANS. However, we can only do this for BOOLEANS that we have added for V2. I've looked through and this is the only instance where I can see this has been done. > >3. H.225.0 Annex H - ASN.1 >All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. We >propose to add this field for UI-UUIE message as well ("for future >sake"): >UI-UUIE ::=SEQUENCE >{ > protocolIdentifier ProtocolIdentifier, > ... > callIdentifier CallIdentifier > >} Since CallIdentifier is becoming such an important parameter then we really need to put it in a place where we can get it in a message independent way, i.e. H323-UserInformation, or H323-UU-PDU. This will also mean that it is in all messages and we don't have to reference it in any new messages we create (i.e. as above). e.g.: H323-UserInformation ::= SEQUENCE -- root for all Q.931 related ASN.1 { h323-uu-pdu H323-UU-PDU, user-data SEQUENCE { protocol-discriminator INTEGER (0..255), user-information OCTET STRING (SIZE(1..131)), ... } OPTIONAL, ..., callIdentifier CallIdentifier } P.S. Can I confirm that even when CallIdentifier is present, the CRV will still have the use and mean that it does in V1? > >4. H.450.2 Clause 10.6.1.1 >This clause is talking about Call Transferring in case of GK Call >Routed model and both Q.931 Signaling and H.245 protocol are "routed" >by the GK. According to H.323V.2 GK's Call Routed model where Q.931 >Signaling is routed by the GK, but H.245 messages flow directly is >legal and more efficient. It seems that the clause above doesn't cover >this case. In order to provide a working solution for this case, an >additional OPTIOANAL field "h245Address" should be added to >Facility-UUIE message as follows: > >H.225.0: Add "h245Address" field to the Facility message: > >Facility-UUIE ::= SEQUENCE >{ > protocolIdentifier ProtocolIdentifier, > alternativeAddress TransportAddress OPTIONAL, > alternativeAliasAddress SEQUENCE OF AliasAddress OPTIONAL, > conferenceID ConferenceIdentifier OPTIONAL, > reason FacilityReason, > ..., > callIdentifier CallIdentifier, > destExtraCallInfo SEQUENCE OF AliasAddress >OPTIONAL, > remoteExtensionAddress AliasAddress OPTIONAL, > tokens SEQUENCE OF ClearToken >OPTIONAL, > cryptoTokens SEQUENCE OF CryptoH323Token >OPTIONAL, > conferences SEQUENCE OF ConferenceList >OPTIONAL, > h245Address TransportAddress OPTIONAL > >} Three things on this: Firstly the call model you described is marked as for further study in 7.3.2/H.323. This was presumably done for a good reason and we shouldn't change it without understanding why we did it. (I think Mark was the one who said why the model wouldn't work, but I'm not sure.) Secondly, the facility message described in H.450.2 section is not the same as the Facility-UUIE that you mention above. Thirdly, the H.245 address would not be needed in the Facility-UUIE because it is determined using the usual means of getting it, e.g. in SETUP, ALERTING, CONNECT etc. > >Thanks, > >Orit Levin >RADVision Inc. E Mail: orit(a)radvision.com >575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 >Mahwah, NJ 07430 Fax: 201-529-3516 >

1 0

Remarks on H.450.x and H.225.0
by Orit Levin 01 Dec '97

01 Dec '97

Hello, Editors! We are working know on the Supplementary Services stuff and came across some pitfalls in the last (Geneva) versions of the above protocols. It would be helpful to fix them before Geneva. I am listing them below: 1. H.450.2 Clause 10.5 <<FACILITY message containing a callTransferInitiate invoke APDU and conferenceGoal = "invite">> is mentioned here. There is no conferenceGoal in FACILITY message. Possibly this mistake derives from the SETUP message, mentioned later in the same clause, which indeed has conferenceGoal field. 2. H.225.0 Annex H - ASN.1 InfoRequestResponse ::= SEQUENCE --(IRR) { nonStandardData NonStandardParameter OPTIONAL, . . perCallInfo SEQUENCE OF SEQUENCE { . . originator BOOLEAN, . . } OPTIONAL, ..., . . } The field "originator" is no longer OPTIONAL (the way it was defined in V.1), which makes the situation NOT backward compatible. Was there any reason for that change, or it just a mistake? In any case, because of the ASN.1 encoding rules, this situation highly undesirable. 3. H.225.0 Annex H - ASN.1 All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. We propose to add this field for UI-UUIE message as well ("for future sake"): UI-UUIE ::=SEQUENCE { protocolIdentifier ProtocolIdentifier, ... callIdentifier CallIdentifier } 4. H.450.2 Clause 10.6.1.1 This clause is talking about Call Transferring in case of GK Call Routed model and both Q.931 Signaling and H.245 protocol are "routed" by the GK. According to H.323V.2 GK's Call Routed model where Q.931 Signaling is routed by the GK, but H.245 messages flow directly is legal and more efficient. It seems that the clause above doesn't cover this case. In order to provide a working solution for this case, an additional OPTIOANAL field "h245Address" should be added to Facility-UUIE message as follows: H.225.0: Add "h245Address" field to the Facility message: Facility-UUIE ::= SEQUENCE { protocolIdentifier ProtocolIdentifier, alternativeAddress TransportAddress OPTIONAL, alternativeAliasAddress SEQUENCE OF AliasAddress OPTIONAL, conferenceID ConferenceIdentifier OPTIONAL, reason FacilityReason, ..., callIdentifier CallIdentifier, destExtraCallInfo SEQUENCE OF AliasAddress OPTIONAL, remoteExtensionAddress AliasAddress OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, conferences SEQUENCE OF ConferenceList OPTIONAL, h245Address TransportAddress OPTIONAL } Thanks, Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Re: $$ BOOKS, SOFTWARE, CD'S, VIDEO ETC. - DEEP DISCOUNTS $$
by sross 01 Dec '97

01 Dec '97

Please remove me from from mailing list. At 03:59 AM 11/28/97 -0800, you wrote: >Do you buy a lot of books, CDs, cassettes, videos and software? Would you >like to save BIG money on ALL of these products you buy, not just a few titles >as offered by the better known online book and video stores? > >We carry all subject categories. Audio tapes, books on tape, hardcover, >paperbacks, music CDs, cassettes, movie videos and software too. Our >discounts apply to even special orders, unlike the better known online stores. >You get discounts on EVERYTHING !!! > >Send us the titles, author, ISBN number or any of these and we will get back >to you with REAL discounts !!! > >We ship all over the world at the CHEAPEST rates we can get. You save even >more money. > >Be sure to put "books etc inquiry" in subject line to get to the right department. > >Thank you >alternatives(a)alternativeproducts.com > ____________________________________________________ Scott A. Ross, Director of Software Zydacron, Inc. 7 Perimeter Rd, Manchester, N.H. 03103 Phone:(603)647-1000 Fax: (603)647-9470 E-mail: sross(a)zydacron.com VideoPhone: 1(700)734-7993

1 0

GCL ftp site is currently in trouble
by Sakae Okubo 01 Dec '97

01 Dec '97

Dear Q.12-14/16 experts, GCL ftp site (ftp://itu-t:sg15!avc@ftp.gctech.co.jp) is currently in trouble. Until we can solve the problem, please access its mirror site (many thanks to PictureTel efforts to maintain this mirror site): ftp://standard.pictel.com/avc-site/ Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0