- sg16-avd - lists.packetizer.com

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 22 Sep '03

22 Sep '03

Tamura-san, > Quesionts. > > We already have 4 versions. > 0 1998 ASN.1 syntax > 1 1998 ASN.1 syntax > 2 2002 ASN.1 syntax > 3 2002 ASN.1 syntax > > If we introduce the new attribute "syntax2002" in t38faxprofile, > how does it work? Of course, understand that we're just "talking out loud" at the moment. We don't have a clear proposal for this. But, the idea is that new systems would only accept a proposal for a version that it understands and that they would include the "syntax2002" field in any proposals and replies. The "syntax2002" field might just be a NULL type (no real meaning). When encoding the outgoing Fast Connect proposals, the new device would include the "syntax2002" field. New devices would properly decode the field and re-encode it when replying. Seeing the field in the reply, the originating device would know without a doubt that the called device supports the proposed version. If, on the other hand, the called device is an older device, when the proposal is decoded, the "syntax2002" field would not be decoded... it would simply be thrown away by the ASN.1 PER decoder. Thus, when composing a reply, the field would not be present. This would indicate to the calling device that, in spite of the fact that the new device replied with, say, "version=2", the version in use is really not version 2. In that case, the calling device would use the 1998 syntax. > For example, the future implementation with "syntax2002" talks to > the current version 3 implementation without "syntax2002". > In this case, the future one judges from the attribute "version" > and use "2002 ASN.1 syntax". Is it right? I am not aware of any shipping v3 products. What I would propose is that we make an amendment to T.38 Annex B and H.323 Annex D to require that H.323 entities only accept Fast Connect proposals for the specific version of T.38 it support. If there are shipping T38v3 products, then this might be an issue. However, I have not fully looked into what might be the consequences of a called device accepting a v3 proposal when it is actually a v2 device. Would there potentially be data in the IFP packets from a v3 that would fail to decode properly by the v2 device? (I know the 2002 syntax was extended in Amendment 1, but I'm not sure if there is any harm in ignoring the additional fields.) Perhaps you can provide me with further information about that. > But, how about one between the version 3 implmentation > and the version 1 implmentation? From your explanation, sometimes it works > and sometimes it doesn't. Is it unavoidable? I do not understand your question. Can you elaborate? > One more question. > If we have "syntax2002", is the new T.38 version, which is 4, necessary? No, this would be an addition to H.245. We may need to require a new version of H.245, though. We should make an amendment to T.38 Annex B and H.323 Annex D, as I mentioned. We should encourage devices to advertise multiple T.38 version proposals in fastStart in the outgoing Setup to increase the likelihood that the called device can accept at least one of the proposed T.38 versions. > If possible, could you please specify your idea of some description or anything > that is written in T.38 Recommendation. Does the explanation above help clarify the proposed solution? > Maybe, there are somthing that I do not understand. Don't worry.. it's confusing :-) Are you confused about the problem or the proposed solution to the problem? I suppose another thing I should say is that we could potentially introduce H.460.6 (Extendeed Fast Connect) to help resolve this issue, as well. With that, we would not necessarily have to make several proposals. Instead, would could make a single proposal and the called side could make a counter-proposal to "negotiate" the version that should be used. I am not aware of any H.460.6 implementations, yet, though there are certainly a number of cases wherein H.460.6 would be very useful. This is just one. Paul > > Regards, > -- > Hiroshi Tamura > > > From: "Paul E. Jones" <paulej(a)packetizer.com> > Subject: Re: H.323 Fast Connect and Versioning > Date: Tue, 16 Sep 2003 10:39:32 -0400 > > > Peter, > > > > To address there V0/V2 interop problem, I agree that something like the > > syntax2002 would be useful. In fact, to answer your question about > > other H.245 fields that are unknown to the other side... that's > > precisely how things get quite naturally "dropped out" in the replies > > back. It's an indicator to the originator. > > > > Looking past v2 to the subsequent revisions, what else might change? > > Perhaps the syntax will remain unchanged or at least compatible, but > > perhaps something else in the procedures might changes. This is what > > I'm wondering if we should insert rules into H.323 (and Annex D would be > > the candidate for fax) that says that you shall not accept a proposal in > > Fast Connect for a version you do not support? > > > > The proper solution to this general problem, in my opinion, is to > > advertise termcaps in the Setup (perhaps the parallelH245Control field), > > along with Fast Connect, and then use either H.460.6 to re-negotiate > > offered channels or use H.245 logical channel signaling. There's > > certainly nothing wrong with not using Fast Connect at all, but it seems > > to be quite popular and probably something I would not want to disallow. > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter <mailto:PeterP@vegastream.com> Price > > To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; > > tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> > > Sent: Tuesday, September 16, 2003 5:00 AM > > Subject: RE: H.323 Fast Connect and Versioning > > > > Paul, > > > > I appreciate that Version 3, 4 etc don't exist yet but the issue we are > > talking about here is a specific problem caused by an editorial error > > when T.38 was first published that has resulted in an incompatible > > payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it > > will not send a payload that is decodable by the V2 endpoint (and the V2 > > endpoint will send undecodable packets to the other endpoint). T.38 is > > broken. > > > > At this stage we have to assume that such an incompatibility would be > > avoided in future versions. If a future change to the standard resulted > > in a new incompatibility with V2 then again it is effectively a new > > codec and that future version would have to be protected in some way > > from V2 or older versions. Since (nearly) all the fields are now > > extensible unless someone decides we need a third error recovery > > mechanism it's hard to see how T.38 can be broken again. > > > > It may well be that the Fast Connect rules should be reviewed but I do > > not think this is the scenario that should drive the thinking. You say > > that the video options can't be changed but what happens when your > > endpoint doesn't understand them (ie can't decode them). What will the > > calling endpoint do when it receives a response that has probably been > > changed? > > > > I suspect that this changing of extended options will be the real issue > > in the future as this will (should) be where differences between > > versions will exist and any modifications to the Fast Connect rules can > > usefully address this type of predictable issue. I still haven't seen > > any response from video endpoint implementors who must have encountered > > this scenario and must have views on how it should be handled. Maybe > > they are not looking at this list and the question needs to be asked on > > the implementors list. > > > > > > The T.38 problem does not fall into this category, it is a result of an > > error in the standard and there is no way of of trying to anticipate > > future problems caused by errors (and no point or gain). The errors > > won't be the same (I hope) and will almost certainly require unique > > solutions. > > > > > > I am not convinced about your suggestion for changing Annex D. This is > > an interoperability issue between new implementations and old ones. > > Changing the standard in this way isn't going to stop existing endpoints > > accepting the channels [ unless you have some very interesting > > paranormal capabilities in your gateway - in which case why do you need > > H.323 at all! Or have you have achieved the ultimate goal - a computer > > that does what you want it to do, not what you tell it to do ;-) ] > > > > I still believe that the syntax2002 suggestion by itself is the best > > solution for this problem. > > 1. It allows the calling endpoint to identify which version of the ASN.1 > > it should use for both receive and transmit. > > 2. It does not require any knowledge of the problem in existing V0/V1 > > endpoints (a very important factor) > > 3. It is an isolated change that resolves the current problem and does > > not have any consequences for any other application area. > > 4. Trying to engineer a solution that can anticipate the unforeseeable > > future will continue to make your head hurt ;-) > > > > Incidentally, since syntax2002 would be an extended option in > > T38FaxProfile it would be covered by Fast Connect changes that allowed > > such options to be dropped. > > > > BTW I agree that not using Fast Connect at all is the best solution. > > H.245 tunneling or even an H.245 address in the Setup message typically > > allows the media to be established before any useful data can be > > transmitted - even a purely electronic IVR system is going to delay > > before transmitting a message to us poor slow humans. In fact, media can > > be established more quickly because it does not require any call > > progress messages - not many endpoints accept Fast Connect in Facility > > messages. > > > > Pete > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 12 September 2003 21:53 > > To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int > > Subject: Re: H.323 Fast Connect and Versioning > > > > > > Peter, > > > > The danger with adding the codepoint for "syntax2002" is that it does > > not necessarily encompass all of the rules for version 2, 3, etc. Since > > those future versions do not exist, it presents us with certain > > problems. > > > > Perhaps the right solution is two-fold: > > > > 1. Add a new "syntax2002" field > > > > 2. Allow the called endpoint to modify the version number field in > > the Fast Connect proposal. It could *not* change it if the calling > > device is version 0 or not using the new "syntax2002" field, but we > > could add a rule that says that if the calling device included > > "syntax2002", it also means that the called device may change the > > version number in the reply to indicate the actual supported version. > > > > If we do (2), then we need to change the language in H.323 to say that > > parameters shall not be changed, unless explicitly allowed by the > > particular "controlling media profile document". For T.38, that would > > be Annex D/H.323. For V.150.1, that would be Annex P/H.323. > > > > The video codec issue is an interesting one... several options can be > > proposed with various capabilities, but they can't be changed. > > > > There is an implementation approach that could be used to solve these > > kinds of issues, but some folks don't like it. That is: don't use Fast > > Connect at all-- just do termcap exchange and only open media channels > > and ring the remote phone once caps are exchanged and media is opened. > > Regardless of whether H.245 is tunneled or on a separate connection, the > > exchange of all required messages can be done in about 3 TCP packets per > > side. > > > > As for the requirement that H.245 tunneling be used with Fast Connect--- > > yes, the requirement is there, but folks ignore that like they do other > > requirements in the standard ;-) The wording might be "must support > > tunneling", which does not mean it has to be used. > > > > Fast Connect certainly has certain advantages over H.245, but if we had > > never introduced Fast Connect in the first place, I suspect nobody would > > think something is missing. Most likely, folks would have engineered > > their products to send TCS right away, would not have alerted the user > > until media was established, etc. They would have optimized their code > > to send TCS,MSDet,OLC in the first outgoing message, replied with > > TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then > > TCSAck,OLCAck in the sender's second TCP packet. In the rare case where > > the proposed OLC is not acceptable, it would require an extra exchange > > of messages, but certainly no worse than Fast Connect today. > > > > I'm actually working on a new extension to H.323 to allowing the calling > > endpoint to explicitly request that the call establishment be delayed > > until a certain point (e.g., bi-directional media channels are opened). > > The calling side can control when it lets the call proceed. Likewise, > > the called side can control it by not acknowledging that the requested > > "delay point" has been reached. This might be the better way to handle > > T.38.... except that, as you point out, there are Fast Connect-only T.38 > > devices. > > > > My head hurts... > > > > I really hate to break the rules about changing the attributes of a Fast > > Connect proposal. > > > > Here's another thought: What if we add text to Annex D/H.323 that says > > that if the proposed version is not supported, then it shall not accept > > the proposal. If it wants to offer a "counter proposal", it has two > > means: H.245 signaling or H.460.6 (Extended Fast Connect). > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter <mailto:PeterP@vegastream.com> Price > > To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; > > tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> > > Sent: Thursday, September 11, 2003 3:53 AM > > Subject: RE: H.323 Fast Connect and Versioning > > > > > > Paul, > > > > as I said before any solution is likely to be a bit dirty because of the > > nature of the problem. I think your "syntax2002" suggestion is > > perfectly valid - it is a smaller more localised change and, especially > > given the reluctance to add new code points, is probably a better > > alternative than t39faxV2. It only requires a single change to > > T38FaxProfile rather than changes to both DataApplicationCapability and > > DataApplicationMode. There is no danger that the change could affect > > anything other than T.38 aware endpoints. > > > > On the subject of H245 tunneling, the problem scenario we're discussing > > is Fast Connect and I thought that H.323 V4 says that endpoints using > > Fast Connect shall use H.245 tunneling! It doesn't do much for pure > > T.38 endpoints which don't do any H.245 though. > > > > > > The thread has suggested two approaches > > 1. resolve the issue within the Fast Connect proposal (or any > > subsequent requestMode/OLC etc) > > 2. resolve the issue by modifying some other part of the standard by > > introducing "special cases" > > > > As an implementor, I would prefer to see a solution within the Fast > > Connect proposal rather than force other changes in the standard - the > > danger of going that route is you don't know what the downstream > > consequences are going to be. Containing the solution in T38FaxProfile > > keeps implementation simpler - you receive a message and you know > > exactly what you are doing without having to go looking for other > > information. Logically, the tunneled H245 messages arrive after the > > Setup message and its easier to process the Setup completely before > > starting to look at the H.245. > > > > Furthermore, if H.323 endpoints are to remain interoperable with pure > > T.38 endpoints (are there any?) then the solution *must* be contained > > within the Fast Connect proposal. > > > > You suggest that "syntax002" is a bit of a kludge. It probably is but > > it does have the advantage of being isolated. I think that "special > > cases" in the standard that may have unforeseen consequences for > > endpoints that are not interested in T.38 are very much worse. > > > > ------------ > > > > A slight aside here (but related). > > > > Your remark about the way that all endpoints appear to decode and > > re-encode the Fast Connect proposals implies that the rule for not > > changing the proposals is effectively impossible to maintain. > > > > I only work with audio endpoints that use the basic audio codecs and > > T.38 so until this discussion started hadn't really thought about this > > issue. It's easy to say you musn't change, say, the frame count of G729 > > but for codecs that are defined as extensible like T.38 (and all the > > video codecs) there will always be a problem when new endpoints offer > > new features to old endpoints. > > > > Perhaps the Fast Connect rule needs some review to address the specific > > issue of extensible capabilities. > > Have video endpoints already encountered this problem? > > Do any video endpoint implementors have any relevent comments here? > > > > Peter > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 10 September 2003 23:35 > > To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int > > Subject: Re: H.323 Fast Connect and Versioning > > > > > > Peter, > > > > I've only seen this problem with fax. To answer your last question, > > I've only seen T.38 use this kind of version tag. However, V.150.1 also > > has versioning information as part of the object identifier that > > identifies the capability. This will be interesting to see if we > > introduce the same kind of problem there. In general, it's just not > > good to advertise the version through an OLC... it's better to perform a > > full caps exchange. The trouble is that modem and (to some extent) fax > > timings are such that we must open channels ASAP... before a caps > > exchange. (Actually, we could transmit the termcap set in the Setup > > message, but few devices support that.) > > > > We have had non-compatible payload specifications before and we resolved > > that by adding new code points. However, we've been trying to avoid > > that. Even so, we could do it again... it's just less desirable. > > > > I had another idea. What we could do is, within the t38faxProtocol > > SEQUENCE, we could indicate which syntax is to be used. Older devices > > would not see this field and would not decode it. So, when the reply is > > re-encoded, it would not be present. So, even if the version was set to > > "2", the "Syntax2002" field, say, would not be present. This would mean > > that the 1998 syntax has to be used. A newer endpoint would see the > > field and would properly re-encode it in the reply. This is a bit of a > > kludge and works only because of the way the ASN.1 encoding/decoding > > works with every device I've seen. > > > > Another solution to the problem might be to require that endpoint use > > H.245 tunneling and to advertise their capabilities in the Setup > > message. That could allow us to avoid this problem entirely. I'm just > > not sure how excited people would be to be forced to use H.245 tunneling > > every time they use fax, modem, or text relay. > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter Price <mailto:PeterP@vegastream.com> > > To: 'Paul <mailto:paulej@packetizer.com> E. Jones' ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; > > tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> > > Sent: Wednesday, September 10, 2003 12:34 PM > > Subject: RE: H.323 Fast Connect and Versioning > > > > > > > > Paul, > > > > I wrote the first part of this email and then reread yours - I was > > bogged down in the fax issue but I think you are actually raising a > > wider issue aren't you? See part 2 below. > > > > -------------------------- Part 1 > > I don't believe that 5 versions of T38 would result in 5 offered > > channels. > > > > > > The need for the different capability is due to the fact that what you > > are offering is a payload that is encoded in a different and > > incompatible way. ie its a bit like offering G.729 and the sending > > packets encoded according to G.723.1, they both represent speech but > > they are not going to be played out properly. The single extra bit > > introduced into the T.38 payload packet by the 2002 ASN.1 is backwards > > incompatible. > > > > The problem only exists for endpoints that only know about the 1998 > > ASN.1 and are unaware of the incompatibility - it is important that they > > do not think they can accept the offered channel. > > > > Once an endpoint is aware of the problem (ie it knows about the 2002 > > ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of > > course, this does assume that a similar incompatibilty does not creep > > into the payload ASN.1 in future versions - but that's down to careful > > work in the standard development and editing stage. > > > > I still think adding t38faxV2 (say) to DataApplicationCapability and > > DataApplicationMode is the simplest solution > > [ t38faxV2 would use the same definitions for t38FaxProtocol and > > t38FaxProfile - its only the payload that has changed ]. This protects > > the existing T.38 implementations and avoids the need to break the rule > > about modifying Fast Connect proposals. > > > > The change in the T.38 payload ASN.1 breaks the fundamental backwards > > compatibility that ASN.1 is supposed to guarantee and thus whatever the > > final solution there has to be an element of a hack involved - I think > > that this change would isolate the change and protect the rest of the > > standard. > > > > > > -------------------------- Part 2 > > > > The versioning issue applies to any form of payload, > > voice/video/fax/whatever. > > > > The problem is still going to exist in early versions of endpoints that > > don't understand the consequence of accepting versions that they do not > > understand fully. If a new version of a codec's payload is not > > backwards compatible then I would assert that it is a new codec and must > > be signalled as a different capability. > > > > The issue of multiple variations already exists anyway although not (to > > my knowledge) with version numbers. > > Endpoints already offer multiple packet sizes for exactly the reason > > that you are not supposed to alter the Fast Connect proposal. What > > happens when somebody starts to offer g729Extensions and has to offer > > all the combinations of Annexes because they don't know what the other > > end can use ( I make that 64 proposals in each direction without adding > > further annexes! )? > > > > > > I don't see that relaxing the rule about modifying the version in a Fast > > Connect channel will help resolve the problem of having to offer > > multiple proposals. You either have to allow *anything* to be modified > > or stick to the current rule. Exceptions allowing certain fields to be > > modified just makes life much more difficult and confusing. > > > > > > T.38 is the only codec I am aware of that actually uses a version number > > in this manner. Are there any others? Why was it introduced in T.38? > > Perhaps this is a lesson for the future about the value of introducing > > of such a field in other codecs. > > > > Peter > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 10 September 2003 16:01 > > To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int > > Subject: Re: H.323 Fast Connect and Versioning > > > > > > Peter, > > > > I think you're on the right track. We could avoid ASN.1 changes by > > introducing the new capability as a generic data capability, but a new > > capability is required here, I think. > > > > The problem, as I see it, is that when we use Fast Connect, we can't > > alert the calling side as to what version the called side actually > > supports. This suggests that if we have 5 versions of T.38, the calling > > side would have to propose a channel for each version independently. > > That's horrible. It's only complicated further by the fact that T.38 > > may not be signaled by itself-- it might be part of audio proposals that > > also include modem, text over IP, VBD, or other media. It might even be > > that there are several versions of the modem (V.150.1) protocol > > advertised. > > > > I think the only real solution to this problem is to allow the Fast > > Connect proposals to be altered by the called endpoint such that they > > can change the version number.. and nothing else. H.323 has an explicit > > statement that says that the proposals can't be modified before > > returning them, but perhaps this simple exception might resolve these > > issues. I think without such, it's going to be terrible complicated. > > > > Paul > > > > > > ----- Original Message ----- > > From: Peter Price <mailto:PeterP@vegastream.com> > > To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; > > itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> > > Sent: Wednesday, September 10, 2003 3:23 AM > > Subject: RE: H.323 Fast Connect and Versioning > > > > Paul wrote > > > > "Perhaps we can require the calling device to not transmit any data > > until it receives at least one IFP packet from the called side and > > determines the ASN.1 version used to encode the message." > > > > Unfortunately this won't work - although typically the called endpoint > > will provide the first IFP (Probably a CED) this doesn't work when you > > poll for a fax - in that case the calling endpoint will probably want to > > send the first IFP. > > > > The only way I can see out of this is to add a new data application > > (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. > > t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - > > and future carefully checked modifications ;-). Now there's no problem, > > a 2002 aware endpoint can offer both versions and a 1998 aware endpoint > > can only accept the ASN.1 it understands. > > > > > > Pete Price > > Vegastream Limited > > > > > > -----Original Message----- > > From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] > > Sent: 09 September 2003 20:32 > > To: itu-sg16(a)external.cisco.com > > Subject: H.323 Fast Connect and Versioning > > > > > > Folks, > > > > Today, I was exchanging e-mail with somebody over the fax version number > > issue and the different syntax that is used (1998 vs 2002). > > > > If we open H.245 and exchange a full set of capabilities, and H.323 > > endpoint could determine the version supported by the other side and > > open a channel supporting that particular version. However, I don't > > think any text is explicitly clear on that. > > > > Another scenario-- and one I have more trouble with-- is Fast Connect. > > If a calling endpoint populates the fastStart element with "version 2" > > proposals, for example, the called side (say, a version 0 device) might > > accept the proposal and return the response. However, it is not allowed > > to modify the version field. The reason is that Fast Connect proposals > > are not ordered in a way such that replies must be ordered the same way. > > Rather, the calling device determines which proposals are accepted based > > on characteristics of the proposals returned (e.g., codec type, samples > > per packet, or other information). In some cases, a calling endpoint > > will actually not try to "match" the proposal returned, but just accept > > it as a proposal and run with it. > > > > The problem is that if a calling device proposes version 2 and the > > called device returns version 2 (but is actually a v0 device), then the > > wrong syntax will be transmitted on the wire. Thus, the text needs to > > state somewhere one of these options (or something similar): > > > > 1. The calling device must offer a proposal for each version it > > wants to potentially use and the called device must accept the first > > proposal it can accept (in order of the proposals) and the called device > > must not accept any proposal for a version it does not support > > > > 2. The calling device must wait for capability exchange to complete > > to determine the actual supported version of the other device > > > > Alternatively, we could make an allowance for the endpoint to change the > > version number in the Fast Connect proposal, but I don't think that's a > > good idea, as it would quite possibly break interoperability with some > > devices. > > > > What would a version 0 device do today if it received a Fast Connect > > proposal advertising version 2? Would it accept it? I suspect so and > > I'm afraid that we might have some interop problems regardless of the > > direction we go. > > > > Perhaps we can require the calling device to not transmit any data until > > it receives at least one IFP packet from the called side and determines > > the ASN.1 version used to encode the message. As much as we can push > > onto the shoulders of a v2 device, the better, as I don't think we have > > any real deployments in the field (yet)... might be wrong, but I think > > it would be a far less significant impact on that side. > > > > I'm open to suggestions. Perhaps this issue is even addressed and I've > > simply overlooked it. > > > > Thanks, > > Paul > > > > > > >

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 20 Sep '03

20 Sep '03

Ernst, Sorry for the delayed reply. I've been busy the latter part of the week and just now catching up on some standards e-mail. Here's the problem: a.. Suppose a T.38v2 devices calls a T.38v0 device, proposing T.38v2 in Fast Connect. b.. The called T.38v0 device will accept the T.38v2 proposal... there is no text to tell it not to. c.. The called T.38v0 device returns a fastStart element containing v2! d.. The calling device then sends IFP packets encoded according to the 2002 syntax, which will fail to decode. If we had text in H.323 Annex D or elsewhere that said that an endpoint shall not accept a proposal for a version higher than it understands, that would be OK. However, we don't have such rules. If we forced the endpoints to at least pass the capability set messages in the Setup and response to Fast Connect, that would also address the issue... but we don't have that requirement either. So, we need two things: 1.. We need to address this versioning issue quite explicitly 2.. We need some "kludge" to allow v2 devices to work properly with v0 devices that accept a v2 fastStart proposal Paul ----- Original Message ----- From: Horvath Ernst To: 'paulej(a)PACKETIZER.COM' Cc: itu-sg16(a)external.cisco.com Sent: Wednesday, September 17, 2003 4:55 AM Subject: AW: H.323 Fast Connect and Versioning Paul, I still don't see why the existing version field in the t38FaxProfile isn't sufficient and how an additional syntax2002 field would help much. If an old implementation returns an unrecognised version field, why should it drop an unrecognised new field? So those implementations still won't behave as expected. The only case where syntax2002 would improve things seems to be with version 0/1 implementations that understand the version field and answer incorrectly by returning a "version = 2" field unchanged. Am I right? Ernst -----Ursprüngliche Nachricht----- Von: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Gesendet am: Mittwoch, 17. September 2003 06:26 An: itu-sg16(a)external.cisco.com Betreff: Re: H.323 Fast Connect and Versioning Anatoli, So, I think the first step for T.38 is to add the syntax2002 field. Following that, we need to go back and more clearly define versioning issues for all sub-protocols, including T.38, V.150.1, V.ToIP, V.VBD, etc. All of those will present similar issues. Paul

1 0

AW: H.323 Fast Connect and Versioning
by ernst.horvath＠SIEMENS.COM 17 Sep '03

17 Sep '03

Paul, I still don't see why the existing version field in the t38FaxProfile isn't sufficient and how an additional syntax2002 field would help much. If an old implementation returns an unrecognised version field, why should it drop an unrecognised new field? So those implementations still won't behave as expected. The only case where syntax2002 would improve things seems to be with version 0/1 implementations that understand the version field and answer incorrectly by returning a "version = 2" field unchanged. Am I right? Ernst -----Ursprüngliche Nachricht----- Von: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Gesendet am: Mittwoch, 17. September 2003 06:26 An: itu-sg16(a)external.cisco.com Betreff: Re: H.323 Fast Connect and Versioning Anatoli, So, I think the first step for T.38 is to add the syntax2002 field. Following that, we need to go back and more clearly define versioning issues for all sub-protocols, including T.38, V.150.1, V.ToIP, V.VBD, etc. All of those will present similar issues. Paul

1 0

AW: H.323 Fast Connect and Versioning
by Horvath Ernst 17 Sep '03

17 Sep '03

Paul, I still don't see why the existing version field in the t38FaxProfile isn't sufficient and how an additional syntax2002 field would help much. If an old implementation returns an unrecognised version field, why should it drop an unrecognised new field? So those implementations still won't behave as expected. The only case where syntax2002 would improve things seems to be with version 0/1 implementations that understand the version field and answer incorrectly by returning a "version = 2" field unchanged. Am I right? Ernst -----Ursprüngliche Nachricht----- Von: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Gesendet am: Mittwoch, 17. September 2003 06:26 An: itu-sg16(a)external.cisco.com Betreff: Re: H.323 Fast Connect and Versioning Anatoli, So, I think the first step for T.38 is to add the syntax2002 field. Following that, we need to go back and more clearly define versioning issues for all sub-protocols, including T.38, V.150.1, V.ToIP, V.VBD, etc. All of those will present similar issues. Paul

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 17 Sep '03

17 Sep '03

Anatoli, So, I think the first step for T.38 is to add the syntax2002 field. Following that, we need to go back and more clearly define versioning issues for all sub-protocols, including T.38, V.150.1, V.ToIP, V.VBD, etc. All of those will present similar issues. Paul ----- Original Message ----- From: Anatoli Levine To: 'paulej(a)PACKETIZER.COM' ; itu-sg16(a)external.cisco.com Sent: Tuesday, September 16, 2003 5:31 PM Subject: RE: H.323 Fast Connect and Versioning Paul, adding TermCaps into the Setup in the future versions will not help, as none of the existing applications, which might use V0 syntax, will put termCaps into the Setup. Anatoli -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, September 16, 2003 10:43 AM To: itu-sg16(a)external.cisco.com Subject: Re: H.323 Fast Connect and Versioning Peter, To address there V0/V2 interop problem, I agree that something like the syntax2002 would be useful. In fact, to answer your question about other H.245 fields that are unknown to the other side... that's precisely how things get quite naturally "dropped out" in the replies back. It's an indicator to the originator. Looking past v2 to the subsequent revisions, what else might change? Perhaps the syntax will remain unchanged or at least compatible, but perhaps something else in the procedures might changes. This is what I'm wondering if we should insert rules into H.323 (and Annex D would be the candidate for fax) that says that you shall not accept a proposal in Fast Connect for a version you do not support? The proper solution to this general problem, in my opinion, is to advertise termcaps in the Setup (perhaps the parallelH245Control field), along with Fast Connect, and then use either H.460.6 to re-negotiate offered channels or use H.245 logical channel signaling. There's certainly nothing wrong with not using Fast Connect at all, but it seems to be quite popular and probably something I would not want to disallow. Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Tuesday, September 16, 2003 5:00 AM Subject: RE: H.323 Fast Connect and Versioning Paul, I appreciate that Version 3, 4 etc don't exist yet but the issue we are talking about here is a specific problem caused by an editorial error when T.38 was first published that has resulted in an incompatible payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it will not send a payload that is decodable by the V2 endpoint (and the V2 endpoint will send undecodable packets to the other endpoint). T.38 is broken. At this stage we have to assume that such an incompatibility would be avoided in future versions. If a future change to the standard resulted in a new incompatibility with V2 then again it is effectively a new codec and that future version would have to be protected in some way from V2 or older versions. Since (nearly) all the fields are now extensible unless someone decides we need a third error recovery mechanism it's hard to see how T.38 can be broken again. It may well be that the Fast Connect rules should be reviewed but I do not think this is the scenario that should drive the thinking. You say that the video options can't be changed but what happens when your endpoint doesn't understand them (ie can't decode them). What will the calling endpoint do when it receives a response that has probably been changed? I suspect that this changing of extended options will be the real issue in the future as this will (should) be where differences between versions will exist and any modifications to the Fast Connect rules can usefully address this type of predictable issue. I still haven't seen any response from video endpoint implementors who must have encountered this scenario and must have views on how it should be handled. Maybe they are not looking at this list and the question needs to be asked on the implementors list. The T.38 problem does not fall into this category, it is a result of an error in the standard and there is no way of of trying to anticipate future problems caused by errors (and no point or gain). The errors won't be the same (I hope) and will almost certainly require unique solutions. I am not convinced about your suggestion for changing Annex D. This is an interoperability issue between new implementations and old ones. Changing the standard in this way isn't going to stop existing endpoints accepting the channels [ unless you have some very interesting paranormal capabilities in your gateway - in which case why do you need H.323 at all! Or have you have achieved the ultimate goal - a computer that does what you want it to do, not what you tell it to do ;-) ] I still believe that the syntax2002 suggestion by itself is the best solution for this problem. 1. It allows the calling endpoint to identify which version of the ASN.1 it should use for both receive and transmit. 2. It does not require any knowledge of the problem in existing V0/V1 endpoints (a very important factor) 3. It is an isolated change that resolves the current problem and does not have any consequences for any other application area. 4. Trying to engineer a solution that can anticipate the unforeseeable future will continue to make your head hurt ;-) Incidentally, since syntax2002 would be an extended option in T38FaxProfile it would be covered by Fast Connect changes that allowed such options to be dropped. BTW I agree that not using Fast Connect at all is the best solution. H.245 tunneling or even an H.245 address in the Setup message typically allows the media to be established before any useful data can be transmitted - even a purely electronic IVR system is going to delay before transmitting a message to us poor slow humans. In fact, media can be established more quickly because it does not require any call progress messages - not many endpoints accept Fast Connect in Facility messages. Pete -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 12 September 2003 21:53 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, The danger with adding the codepoint for "syntax2002" is that it does not necessarily encompass all of the rules for version 2, 3, etc. Since those future versions do not exist, it presents us with certain problems. Perhaps the right solution is two-fold: 1.. Add a new "syntax2002" field 2.. Allow the called endpoint to modify the version number field in the Fast Connect proposal. It could *not* change it if the calling device is version 0 or not using the new "syntax2002" field, but we could add a rule that says that if the calling device included "syntax2002", it also means that the called device may change the version number in the reply to indicate the actual supported version. If we do (2), then we need to change the language in H.323 to say that parameters shall not be changed, unless explicitly allowed by the particular "controlling media profile document". For T.38, that would be Annex D/H.323. For V.150.1, that would be Annex P/H.323. The video codec issue is an interesting one... several options can be proposed with various capabilities, but they can't be changed. There is an implementation approach that could be used to solve these kinds of issues, but some folks don't like it. That is: don't use Fast Connect at all-- just do termcap exchange and only open media channels and ring the remote phone once caps are exchanged and media is opened. Regardless of whether H.245 is tunneled or on a separate connection, the exchange of all required messages can be done in about 3 TCP packets per side. As for the requirement that H.245 tunneling be used with Fast Connect--- yes, the requirement is there, but folks ignore that like they do other requirements in the standard ;-) The wording might be "must support tunneling", which does not mean it has to be used. Fast Connect certainly has certain advantages over H.245, but if we had never introduced Fast Connect in the first place, I suspect nobody would think something is missing. Most likely, folks would have engineered their products to send TCS right away, would not have alerted the user until media was established, etc. They would have optimized their code to send TCS,MSDet,OLC in the first outgoing message, replied with TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then TCSAck,OLCAck in the sender's second TCP packet. In the rare case where the proposed OLC is not acceptable, it would require an extra exchange of messages, but certainly no worse than Fast Connect today. I'm actually working on a new extension to H.323 to allowing the calling endpoint to explicitly request that the call establishment be delayed until a certain point (e.g., bi-directional media channels are opened). The calling side can control when it lets the call proceed. Likewise, the called side can control it by not acknowledging that the requested "delay point" has been reached. This might be the better way to handle T.38.... except that, as you point out, there are Fast Connect-only T.38 devices. My head hurts... I really hate to break the rules about changing the attributes of a Fast Connect proposal. Here's another thought: What if we add text to Annex D/H.323 that says that if the proposed version is not supported, then it shall not accept the proposal. If it wants to offer a "counter proposal", it has two means: H.245 signaling or H.460.6 (Extended Fast Connect). Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Thursday, September 11, 2003 3:53 AM Subject: RE: H.323 Fast Connect and Versioning Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price To: 'paulej(a)PACKETIZER.COM' ; itu-sg16(a)external.cisco.com Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1.. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2.. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by alevine＠RADVISION.COM 16 Sep '03

16 Sep '03

Paul, adding TermCaps into the Setup in the future versions will not help, as none of the existing applications, which might use V0 syntax, will put termCaps into the Setup. Anatoli -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, September 16, 2003 10:43 AM To: itu-sg16(a)external.cisco.com Subject: Re: H.323 Fast Connect and Versioning Peter, To address there V0/V2 interop problem, I agree that something like the syntax2002 would be useful. In fact, to answer your question about other H.245 fields that are unknown to the other side... that's precisely how things get quite naturally "dropped out" in the replies back. It's an indicator to the originator. Looking past v2 to the subsequent revisions, what else might change? Perhaps the syntax will remain unchanged or at least compatible, but perhaps something else in the procedures might changes. This is what I'm wondering if we should insert rules into H.323 (and Annex D would be the candidate for fax) that says that you shall not accept a proposal in Fast Connect for a version you do not support? The proper solution to this general problem, in my opinion, is to advertise termcaps in the Setup (perhaps the parallelH245Control field), along with Fast Connect, and then use either H.460.6 to re-negotiate offered channels or use H.245 logical channel signaling. There's certainly nothing wrong with not using Fast Connect at all, but it seems to be quite popular and probably something I would not want to disallow. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Tuesday, September 16, 2003 5:00 AM Subject: RE: H.323 Fast Connect and Versioning Paul, I appreciate that Version 3, 4 etc don't exist yet but the issue we are talking about here is a specific problem caused by an editorial error when T.38 was first published that has resulted in an incompatible payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it will not send a payload that is decodable by the V2 endpoint (and the V2 endpoint will send undecodable packets to the other endpoint). T.38 is broken. At this stage we have to assume that such an incompatibility would be avoided in future versions. If a future change to the standard resulted in a new incompatibility with V2 then again it is effectively a new codec and that future version would have to be protected in some way from V2 or older versions. Since (nearly) all the fields are now extensible unless someone decides we need a third error recovery mechanism it's hard to see how T.38 can be broken again. It may well be that the Fast Connect rules should be reviewed but I do not think this is the scenario that should drive the thinking. You say that the video options can't be changed but what happens when your endpoint doesn't understand them (ie can't decode them). What will the calling endpoint do when it receives a response that has probably been changed? I suspect that this changing of extended options will be the real issue in the future as this will (should) be where differences between versions will exist and any modifications to the Fast Connect rules can usefully address this type of predictable issue. I still haven't seen any response from video endpoint implementors who must have encountered this scenario and must have views on how it should be handled. Maybe they are not looking at this list and the question needs to be asked on the implementors list. The T.38 problem does not fall into this category, it is a result of an error in the standard and there is no way of of trying to anticipate future problems caused by errors (and no point or gain). The errors won't be the same (I hope) and will almost certainly require unique solutions. I am not convinced about your suggestion for changing Annex D. This is an interoperability issue between new implementations and old ones. Changing the standard in this way isn't going to stop existing endpoints accepting the channels [ unless you have some very interesting paranormal capabilities in your gateway - in which case why do you need H.323 at all! Or have you have achieved the ultimate goal - a computer that does what you want it to do, not what you tell it to do ;-) ] I still believe that the syntax2002 suggestion by itself is the best solution for this problem. 1. It allows the calling endpoint to identify which version of the ASN.1 it should use for both receive and transmit. 2. It does not require any knowledge of the problem in existing V0/V1 endpoints (a very important factor) 3. It is an isolated change that resolves the current problem and does not have any consequences for any other application area. 4. Trying to engineer a solution that can anticipate the unforeseeable future will continue to make your head hurt ;-) Incidentally, since syntax2002 would be an extended option in T38FaxProfile it would be covered by Fast Connect changes that allowed such options to be dropped. BTW I agree that not using Fast Connect at all is the best solution. H.245 tunneling or even an H.245 address in the Setup message typically allows the media to be established before any useful data can be transmitted - even a purely electronic IVR system is going to delay before transmitting a message to us poor slow humans. In fact, media can be established more quickly because it does not require any call progress messages - not many endpoints accept Fast Connect in Facility messages. Pete -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 12 September 2003 21:53 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, The danger with adding the codepoint for "syntax2002" is that it does not necessarily encompass all of the rules for version 2, 3, etc. Since those future versions do not exist, it presents us with certain problems. Perhaps the right solution is two-fold: 1. Add a new "syntax2002" field 2. Allow the called endpoint to modify the version number field in the Fast Connect proposal. It could *not* change it if the calling device is version 0 or not using the new "syntax2002" field, but we could add a rule that says that if the calling device included "syntax2002", it also means that the called device may change the version number in the reply to indicate the actual supported version. If we do (2), then we need to change the language in H.323 to say that parameters shall not be changed, unless explicitly allowed by the particular "controlling media profile document". For T.38, that would be Annex D/H.323. For V.150.1, that would be Annex P/H.323. The video codec issue is an interesting one... several options can be proposed with various capabilities, but they can't be changed. There is an implementation approach that could be used to solve these kinds of issues, but some folks don't like it. That is: don't use Fast Connect at all-- just do termcap exchange and only open media channels and ring the remote phone once caps are exchanged and media is opened. Regardless of whether H.245 is tunneled or on a separate connection, the exchange of all required messages can be done in about 3 TCP packets per side. As for the requirement that H.245 tunneling be used with Fast Connect--- yes, the requirement is there, but folks ignore that like they do other requirements in the standard ;-) The wording might be "must support tunneling", which does not mean it has to be used. Fast Connect certainly has certain advantages over H.245, but if we had never introduced Fast Connect in the first place, I suspect nobody would think something is missing. Most likely, folks would have engineered their products to send TCS right away, would not have alerted the user until media was established, etc. They would have optimized their code to send TCS,MSDet,OLC in the first outgoing message, replied with TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then TCSAck,OLCAck in the sender's second TCP packet. In the rare case where the proposed OLC is not acceptable, it would require an extra exchange of messages, but certainly no worse than Fast Connect today. I'm actually working on a new extension to H.323 to allowing the calling endpoint to explicitly request that the call establishment be delayed until a certain point (e.g., bi-directional media channels are opened). The calling side can control when it lets the call proceed. Likewise, the called side can control it by not acknowledging that the requested "delay point" has been reached. This might be the better way to handle T.38.... except that, as you point out, there are Fast Connect-only T.38 devices. My head hurts... I really hate to break the rules about changing the attributes of a Fast Connect proposal. Here's another thought: What if we add text to Annex D/H.323 that says that if the proposed version is not supported, then it shall not accept the proposal. If it wants to offer a "counter proposal", it has two means: H.245 signaling or H.460.6 (Extended Fast Connect). Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Thursday, September 11, 2003 3:53 AM Subject: RE: H.323 Fast Connect and Versioning Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

RE: H.323 Fast Connect and Versioning
by Anatoli Levine 16 Sep '03

16 Sep '03

Paul, adding TermCaps into the Setup in the future versions will not help, as none of the existing applications, which might use V0 syntax, will put termCaps into the Setup. Anatoli -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, September 16, 2003 10:43 AM To: itu-sg16(a)external.cisco.com Subject: Re: H.323 Fast Connect and Versioning Peter, To address there V0/V2 interop problem, I agree that something like the syntax2002 would be useful. In fact, to answer your question about other H.245 fields that are unknown to the other side... that's precisely how things get quite naturally "dropped out" in the replies back. It's an indicator to the originator. Looking past v2 to the subsequent revisions, what else might change? Perhaps the syntax will remain unchanged or at least compatible, but perhaps something else in the procedures might changes. This is what I'm wondering if we should insert rules into H.323 (and Annex D would be the candidate for fax) that says that you shall not accept a proposal in Fast Connect for a version you do not support? The proper solution to this general problem, in my opinion, is to advertise termcaps in the Setup (perhaps the parallelH245Control field), along with Fast Connect, and then use either H.460.6 to re-negotiate offered channels or use H.245 logical channel signaling. There's certainly nothing wrong with not using Fast Connect at all, but it seems to be quite popular and probably something I would not want to disallow. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Tuesday, September 16, 2003 5:00 AM Subject: RE: H.323 Fast Connect and Versioning Paul, I appreciate that Version 3, 4 etc don't exist yet but the issue we are talking about here is a specific problem caused by an editorial error when T.38 was first published that has resulted in an incompatible payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it will not send a payload that is decodable by the V2 endpoint (and the V2 endpoint will send undecodable packets to the other endpoint). T.38 is broken. At this stage we have to assume that such an incompatibility would be avoided in future versions. If a future change to the standard resulted in a new incompatibility with V2 then again it is effectively a new codec and that future version would have to be protected in some way from V2 or older versions. Since (nearly) all the fields are now extensible unless someone decides we need a third error recovery mechanism it's hard to see how T.38 can be broken again. It may well be that the Fast Connect rules should be reviewed but I do not think this is the scenario that should drive the thinking. You say that the video options can't be changed but what happens when your endpoint doesn't understand them (ie can't decode them). What will the calling endpoint do when it receives a response that has probably been changed? I suspect that this changing of extended options will be the real issue in the future as this will (should) be where differences between versions will exist and any modifications to the Fast Connect rules can usefully address this type of predictable issue. I still haven't seen any response from video endpoint implementors who must have encountered this scenario and must have views on how it should be handled. Maybe they are not looking at this list and the question needs to be asked on the implementors list. The T.38 problem does not fall into this category, it is a result of an error in the standard and there is no way of of trying to anticipate future problems caused by errors (and no point or gain). The errors won't be the same (I hope) and will almost certainly require unique solutions. I am not convinced about your suggestion for changing Annex D. This is an interoperability issue between new implementations and old ones. Changing the standard in this way isn't going to stop existing endpoints accepting the channels [ unless you have some very interesting paranormal capabilities in your gateway - in which case why do you need H.323 at all! Or have you have achieved the ultimate goal - a computer that does what you want it to do, not what you tell it to do ;-) ] I still believe that the syntax2002 suggestion by itself is the best solution for this problem. 1. It allows the calling endpoint to identify which version of the ASN.1 it should use for both receive and transmit. 2. It does not require any knowledge of the problem in existing V0/V1 endpoints (a very important factor) 3. It is an isolated change that resolves the current problem and does not have any consequences for any other application area. 4. Trying to engineer a solution that can anticipate the unforeseeable future will continue to make your head hurt ;-) Incidentally, since syntax2002 would be an extended option in T38FaxProfile it would be covered by Fast Connect changes that allowed such options to be dropped. BTW I agree that not using Fast Connect at all is the best solution. H.245 tunneling or even an H.245 address in the Setup message typically allows the media to be established before any useful data can be transmitted - even a purely electronic IVR system is going to delay before transmitting a message to us poor slow humans. In fact, media can be established more quickly because it does not require any call progress messages - not many endpoints accept Fast Connect in Facility messages. Pete -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 12 September 2003 21:53 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, The danger with adding the codepoint for "syntax2002" is that it does not necessarily encompass all of the rules for version 2, 3, etc. Since those future versions do not exist, it presents us with certain problems. Perhaps the right solution is two-fold: 1. Add a new "syntax2002" field 2. Allow the called endpoint to modify the version number field in the Fast Connect proposal. It could *not* change it if the calling device is version 0 or not using the new "syntax2002" field, but we could add a rule that says that if the calling device included "syntax2002", it also means that the called device may change the version number in the reply to indicate the actual supported version. If we do (2), then we need to change the language in H.323 to say that parameters shall not be changed, unless explicitly allowed by the particular "controlling media profile document". For T.38, that would be Annex D/H.323. For V.150.1, that would be Annex P/H.323. The video codec issue is an interesting one... several options can be proposed with various capabilities, but they can't be changed. There is an implementation approach that could be used to solve these kinds of issues, but some folks don't like it. That is: don't use Fast Connect at all-- just do termcap exchange and only open media channels and ring the remote phone once caps are exchanged and media is opened. Regardless of whether H.245 is tunneled or on a separate connection, the exchange of all required messages can be done in about 3 TCP packets per side. As for the requirement that H.245 tunneling be used with Fast Connect--- yes, the requirement is there, but folks ignore that like they do other requirements in the standard ;-) The wording might be "must support tunneling", which does not mean it has to be used. Fast Connect certainly has certain advantages over H.245, but if we had never introduced Fast Connect in the first place, I suspect nobody would think something is missing. Most likely, folks would have engineered their products to send TCS right away, would not have alerted the user until media was established, etc. They would have optimized their code to send TCS,MSDet,OLC in the first outgoing message, replied with TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then TCSAck,OLCAck in the sender's second TCP packet. In the rare case where the proposed OLC is not acceptable, it would require an extra exchange of messages, but certainly no worse than Fast Connect today. I'm actually working on a new extension to H.323 to allowing the calling endpoint to explicitly request that the call establishment be delayed until a certain point (e.g., bi-directional media channels are opened). The calling side can control when it lets the call proceed. Likewise, the called side can control it by not acknowledging that the requested "delay point" has been reached. This might be the better way to handle T.38.... except that, as you point out, there are Fast Connect-only T.38 devices. My head hurts... I really hate to break the rules about changing the attributes of a Fast Connect proposal. Here's another thought: What if we add text to Annex D/H.323 that says that if the proposed version is not supported, then it shall not accept the proposal. If it wants to offer a "counter proposal", it has two means: H.245 signaling or H.460.6 (Extended Fast Connect). Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Thursday, September 11, 2003 3:53 AM Subject: RE: H.323 Fast Connect and Versioning Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

Re: using H245 tunneling flag in H323V3
by paulej＠PACKETIZER.COM 16 Sep '03

16 Sep '03

Sachin, > Following has been added in H323 Version-4: > If the called entity does not yet know if H.245 tunneling can be > supported, it shall include the provisionalRespToH245Tunneling flag. This > may happen, for example, when a Gatekeeper is responding to a calling > entity with a message such as Call Proceeding before the called endpoint > responds to the h245Tunneling flag. The provisionalRespToH245Tunneling flag > effectively eliminates the meaning of the h245Tunneling flag in a message > and the flag shall thus be ignored by the receiving endpoint. > > I want to know how to take care of the same in h323 version-3. > > The Scenario is as follows: > 1. Calling endpoint sends a Setup (h245 tunneling = TRUE) message to a > gatekeeper. > 2. Gatekeeper forwards the Setup (h245 tunneling = TRUE) message to the > called endpoint and sends a CallProceeding (h245 tunneling = TRUE) message > to the calling endpoint. It would not be strictly valid for the GK to set the tunneling flag to TRUE or FALSE, really. This is the problem. It really does not know! Of the Gatekeeper sends a Call Proceeding, it should probably wait to get a Call Proceeding from the upstream entity to ensure that the flag is properly set. The problem, of couse, is that takes time. So, I'd take the same approach and set the flag to true and what I would do is have the Gatekeeper tunnel the H.245-- even if it does not use H.245 tunneling to the destination endpoint. > 3. Called endpoint sends a Alerting (h245 tunneling = False) to the > gatekeeper, and gatekeeper forwards this message to the calling endpoint. That would certainly turn off tunneling. > H245 signaling is direct between the endpoints. > > After step # 3, what should be the behaviour of the Calling Endpoint? How > the H245 signaling would be completed? If you perform step 3, the calling endpoint shall not transmit any additional H.245 messages and shall establish a separate connection for H.245 messages from that point forward. If it knows the h245Address, then it may initiate a TCP connection. If it does not, it may send a Facility with startH245. Paul

1 0

Re: H.323 Fast Connect and Versioning
by paulej＠PACKETIZER.COM 16 Sep '03

16 Sep '03

Peter, To address there V0/V2 interop problem, I agree that something like the syntax2002 would be useful. In fact, to answer your question about other H.245 fields that are unknown to the other side... that's precisely how things get quite naturally "dropped out" in the replies back. It's an indicator to the originator. Looking past v2 to the subsequent revisions, what else might change? Perhaps the syntax will remain unchanged or at least compatible, but perhaps something else in the procedures might changes. This is what I'm wondering if we should insert rules into H.323 (and Annex D would be the candidate for fax) that says that you shall not accept a proposal in Fast Connect for a version you do not support? The proper solution to this general problem, in my opinion, is to advertise termcaps in the Setup (perhaps the parallelH245Control field), along with Fast Connect, and then use either H.460.6 to re-negotiate offered channels or use H.245 logical channel signaling. There's certainly nothing wrong with not using Fast Connect at all, but it seems to be quite popular and probably something I would not want to disallow. Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Tuesday, September 16, 2003 5:00 AM Subject: RE: H.323 Fast Connect and Versioning Paul, I appreciate that Version 3, 4 etc don't exist yet but the issue we are talking about here is a specific problem caused by an editorial error when T.38 was first published that has resulted in an incompatible payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it will not send a payload that is decodable by the V2 endpoint (and the V2 endpoint will send undecodable packets to the other endpoint). T.38 is broken. At this stage we have to assume that such an incompatibility would be avoided in future versions. If a future change to the standard resulted in a new incompatibility with V2 then again it is effectively a new codec and that future version would have to be protected in some way from V2 or older versions. Since (nearly) all the fields are now extensible unless someone decides we need a third error recovery mechanism it's hard to see how T.38 can be broken again. It may well be that the Fast Connect rules should be reviewed but I do not think this is the scenario that should drive the thinking. You say that the video options can't be changed but what happens when your endpoint doesn't understand them (ie can't decode them). What will the calling endpoint do when it receives a response that has probably been changed? I suspect that this changing of extended options will be the real issue in the future as this will (should) be where differences between versions will exist and any modifications to the Fast Connect rules can usefully address this type of predictable issue. I still haven't seen any response from video endpoint implementors who must have encountered this scenario and must have views on how it should be handled. Maybe they are not looking at this list and the question needs to be asked on the implementors list. The T.38 problem does not fall into this category, it is a result of an error in the standard and there is no way of of trying to anticipate future problems caused by errors (and no point or gain). The errors won't be the same (I hope) and will almost certainly require unique solutions. I am not convinced about your suggestion for changing Annex D. This is an interoperability issue between new implementations and old ones. Changing the standard in this way isn't going to stop existing endpoints accepting the channels [ unless you have some very interesting paranormal capabilities in your gateway - in which case why do you need H.323 at all! Or have you have achieved the ultimate goal - a computer that does what you want it to do, not what you tell it to do ;-) ] I still believe that the syntax2002 suggestion by itself is the best solution for this problem. 1. It allows the calling endpoint to identify which version of the ASN.1 it should use for both receive and transmit. 2. It does not require any knowledge of the problem in existing V0/V1 endpoints (a very important factor) 3. It is an isolated change that resolves the current problem and does not have any consequences for any other application area. 4. Trying to engineer a solution that can anticipate the unforeseeable future will continue to make your head hurt ;-) Incidentally, since syntax2002 would be an extended option in T38FaxProfile it would be covered by Fast Connect changes that allowed such options to be dropped. BTW I agree that not using Fast Connect at all is the best solution. H.245 tunneling or even an H.245 address in the Setup message typically allows the media to be established before any useful data can be transmitted - even a purely electronic IVR system is going to delay before transmitting a message to us poor slow humans. In fact, media can be established more quickly because it does not require any call progress messages - not many endpoints accept Fast Connect in Facility messages. Pete -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 12 September 2003 21:53 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, The danger with adding the codepoint for "syntax2002" is that it does not necessarily encompass all of the rules for version 2, 3, etc. Since those future versions do not exist, it presents us with certain problems. Perhaps the right solution is two-fold: 1.. Add a new "syntax2002" field 2.. Allow the called endpoint to modify the version number field in the Fast Connect proposal. It could *not* change it if the calling device is version 0 or not using the new "syntax2002" field, but we could add a rule that says that if the calling device included "syntax2002", it also means that the called device may change the version number in the reply to indicate the actual supported version. If we do (2), then we need to change the language in H.323 to say that parameters shall not be changed, unless explicitly allowed by the particular "controlling media profile document". For T.38, that would be Annex D/H.323. For V.150.1, that would be Annex P/H.323. The video codec issue is an interesting one... several options can be proposed with various capabilities, but they can't be changed. There is an implementation approach that could be used to solve these kinds of issues, but some folks don't like it. That is: don't use Fast Connect at all-- just do termcap exchange and only open media channels and ring the remote phone once caps are exchanged and media is opened. Regardless of whether H.245 is tunneled or on a separate connection, the exchange of all required messages can be done in about 3 TCP packets per side. As for the requirement that H.245 tunneling be used with Fast Connect--- yes, the requirement is there, but folks ignore that like they do other requirements in the standard ;-) The wording might be "must support tunneling", which does not mean it has to be used. Fast Connect certainly has certain advantages over H.245, but if we had never introduced Fast Connect in the first place, I suspect nobody would think something is missing. Most likely, folks would have engineered their products to send TCS right away, would not have alerted the user until media was established, etc. They would have optimized their code to send TCS,MSDet,OLC in the first outgoing message, replied with TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then TCSAck,OLCAck in the sender's second TCP packet. In the rare case where the proposed OLC is not acceptable, it would require an extra exchange of messages, but certainly no worse than Fast Connect today. I'm actually working on a new extension to H.323 to allowing the calling endpoint to explicitly request that the call establishment be delayed until a certain point (e.g., bi-directional media channels are opened). The calling side can control when it lets the call proceed. Likewise, the called side can control it by not acknowledging that the requested "delay point" has been reached. This might be the better way to handle T.38.... except that, as you point out, there are Fast Connect-only T.38 devices. My head hurts... I really hate to break the rules about changing the attributes of a Fast Connect proposal. Here's another thought: What if we add text to Annex D/H.323 that says that if the proposed version is not supported, then it shall not accept the proposal. If it wants to offer a "counter proposal", it has two means: H.245 signaling or H.460.6 (Extended Fast Connect). Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Thursday, September 11, 2003 3:53 AM Subject: RE: H.323 Fast Connect and Versioning Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price To: 'Paul E. Jones' ; itu-sg16(a)external.cisco.com ; tsg16q14(a)itu.int Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price To: 'paulej(a)PACKETIZER.COM' ; itu-sg16(a)external.cisco.com Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1.. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2.. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0

Re: H.323 Fast Connect and Versioning
by Paul E. Jones 16 Sep '03

16 Sep '03

Peter, To address there V0/V2 interop problem, I agree that something like the syntax2002 would be useful. In fact, to answer your question about other H.245 fields that are unknown to the other side... that's precisely how things get quite naturally "dropped out" in the replies back. It's an indicator to the originator. Looking past v2 to the subsequent revisions, what else might change? Perhaps the syntax will remain unchanged or at least compatible, but perhaps something else in the procedures might changes. This is what I'm wondering if we should insert rules into H.323 (and Annex D would be the candidate for fax) that says that you shall not accept a proposal in Fast Connect for a version you do not support? The proper solution to this general problem, in my opinion, is to advertise termcaps in the Setup (perhaps the parallelH245Control field), along with Fast Connect, and then use either H.460.6 to re-negotiate offered channels or use H.245 logical channel signaling. There's certainly nothing wrong with not using Fast Connect at all, but it seems to be quite popular and probably something I would not want to disallow. Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Tuesday, September 16, 2003 5:00 AM Subject: RE: H.323 Fast Connect and Versioning Paul, I appreciate that Version 3, 4 etc don't exist yet but the issue we are talking about here is a specific problem caused by an editorial error when T.38 was first published that has resulted in an incompatible payload. The problem is that if a V0/V1 endpoint accepts a V2 offer it will not send a payload that is decodable by the V2 endpoint (and the V2 endpoint will send undecodable packets to the other endpoint). T.38 is broken. At this stage we have to assume that such an incompatibility would be avoided in future versions. If a future change to the standard resulted in a new incompatibility with V2 then again it is effectively a new codec and that future version would have to be protected in some way from V2 or older versions. Since (nearly) all the fields are now extensible unless someone decides we need a third error recovery mechanism it's hard to see how T.38 can be broken again. It may well be that the Fast Connect rules should be reviewed but I do not think this is the scenario that should drive the thinking. You say that the video options can't be changed but what happens when your endpoint doesn't understand them (ie can't decode them). What will the calling endpoint do when it receives a response that has probably been changed? I suspect that this changing of extended options will be the real issue in the future as this will (should) be where differences between versions will exist and any modifications to the Fast Connect rules can usefully address this type of predictable issue. I still haven't seen any response from video endpoint implementors who must have encountered this scenario and must have views on how it should be handled. Maybe they are not looking at this list and the question needs to be asked on the implementors list. The T.38 problem does not fall into this category, it is a result of an error in the standard and there is no way of of trying to anticipate future problems caused by errors (and no point or gain). The errors won't be the same (I hope) and will almost certainly require unique solutions. I am not convinced about your suggestion for changing Annex D. This is an interoperability issue between new implementations and old ones. Changing the standard in this way isn't going to stop existing endpoints accepting the channels [ unless you have some very interesting paranormal capabilities in your gateway - in which case why do you need H.323 at all! Or have you have achieved the ultimate goal - a computer that does what you want it to do, not what you tell it to do ;-) ] I still believe that the syntax2002 suggestion by itself is the best solution for this problem. 1. It allows the calling endpoint to identify which version of the ASN.1 it should use for both receive and transmit. 2. It does not require any knowledge of the problem in existing V0/V1 endpoints (a very important factor) 3. It is an isolated change that resolves the current problem and does not have any consequences for any other application area. 4. Trying to engineer a solution that can anticipate the unforeseeable future will continue to make your head hurt ;-) Incidentally, since syntax2002 would be an extended option in T38FaxProfile it would be covered by Fast Connect changes that allowed such options to be dropped. BTW I agree that not using Fast Connect at all is the best solution. H.245 tunneling or even an H.245 address in the Setup message typically allows the media to be established before any useful data can be transmitted - even a purely electronic IVR system is going to delay before transmitting a message to us poor slow humans. In fact, media can be established more quickly because it does not require any call progress messages - not many endpoints accept Fast Connect in Facility messages. Pete -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 12 September 2003 21:53 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, The danger with adding the codepoint for "syntax2002" is that it does not necessarily encompass all of the rules for version 2, 3, etc. Since those future versions do not exist, it presents us with certain problems. Perhaps the right solution is two-fold: 1. Add a new "syntax2002" field 2. Allow the called endpoint to modify the version number field in the Fast Connect proposal. It could *not* change it if the calling device is version 0 or not using the new "syntax2002" field, but we could add a rule that says that if the calling device included "syntax2002", it also means that the called device may change the version number in the reply to indicate the actual supported version. If we do (2), then we need to change the language in H.323 to say that parameters shall not be changed, unless explicitly allowed by the particular "controlling media profile document". For T.38, that would be Annex D/H.323. For V.150.1, that would be Annex P/H.323. The video codec issue is an interesting one... several options can be proposed with various capabilities, but they can't be changed. There is an implementation approach that could be used to solve these kinds of issues, but some folks don't like it. That is: don't use Fast Connect at all-- just do termcap exchange and only open media channels and ring the remote phone once caps are exchanged and media is opened. Regardless of whether H.245 is tunneled or on a separate connection, the exchange of all required messages can be done in about 3 TCP packets per side. As for the requirement that H.245 tunneling be used with Fast Connect--- yes, the requirement is there, but folks ignore that like they do other requirements in the standard ;-) The wording might be "must support tunneling", which does not mean it has to be used. Fast Connect certainly has certain advantages over H.245, but if we had never introduced Fast Connect in the first place, I suspect nobody would think something is missing. Most likely, folks would have engineered their products to send TCS right away, would not have alerted the user until media was established, etc. They would have optimized their code to send TCS,MSDet,OLC in the first outgoing message, replied with TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then TCSAck,OLCAck in the sender's second TCP packet. In the rare case where the proposed OLC is not acceptable, it would require an extra exchange of messages, but certainly no worse than Fast Connect today. I'm actually working on a new extension to H.323 to allowing the calling endpoint to explicitly request that the call establishment be delayed until a certain point (e.g., bi-directional media channels are opened). The calling side can control when it lets the call proceed. Likewise, the called side can control it by not acknowledging that the requested "delay point" has been reached. This might be the better way to handle T.38.... except that, as you point out, there are Fast Connect-only T.38 devices. My head hurts... I really hate to break the rules about changing the attributes of a Fast Connect proposal. Here's another thought: What if we add text to Annex D/H.323 that says that if the proposed version is not supported, then it shall not accept the proposal. If it wants to offer a "counter proposal", it has two means: H.245 signaling or H.460.6 (Extended Fast Connect). Paul ----- Original Message ----- From: Peter <mailto:PeterP@vegastream.com> Price To: 'Paul E. Jones' <mailto:paulej@packetizer.com> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Thursday, September 11, 2003 3:53 AM Subject: RE: H.323 Fast Connect and Versioning Paul, as I said before any solution is likely to be a bit dirty because of the nature of the problem. I think your "syntax2002" suggestion is perfectly valid - it is a smaller more localised change and, especially given the reluctance to add new code points, is probably a better alternative than t39faxV2. It only requires a single change to T38FaxProfile rather than changes to both DataApplicationCapability and DataApplicationMode. There is no danger that the change could affect anything other than T.38 aware endpoints. On the subject of H245 tunneling, the problem scenario we're discussing is Fast Connect and I thought that H.323 V4 says that endpoints using Fast Connect shall use H.245 tunneling! It doesn't do much for pure T.38 endpoints which don't do any H.245 though. The thread has suggested two approaches 1. resolve the issue within the Fast Connect proposal (or any subsequent requestMode/OLC etc) 2. resolve the issue by modifying some other part of the standard by introducing "special cases" As an implementor, I would prefer to see a solution within the Fast Connect proposal rather than force other changes in the standard - the danger of going that route is you don't know what the downstream consequences are going to be. Containing the solution in T38FaxProfile keeps implementation simpler - you receive a message and you know exactly what you are doing without having to go looking for other information. Logically, the tunneled H245 messages arrive after the Setup message and its easier to process the Setup completely before starting to look at the H.245. Furthermore, if H.323 endpoints are to remain interoperable with pure T.38 endpoints (are there any?) then the solution *must* be contained within the Fast Connect proposal. You suggest that "syntax002" is a bit of a kludge. It probably is but it does have the advantage of being isolated. I think that "special cases" in the standard that may have unforeseen consequences for endpoints that are not interested in T.38 are very much worse. ------------ A slight aside here (but related). Your remark about the way that all endpoints appear to decode and re-encode the Fast Connect proposals implies that the rule for not changing the proposals is effectively impossible to maintain. I only work with audio endpoints that use the basic audio codecs and T.38 so until this discussion started hadn't really thought about this issue. It's easy to say you musn't change, say, the frame count of G729 but for codecs that are defined as extensible like T.38 (and all the video codecs) there will always be a problem when new endpoints offer new features to old endpoints. Perhaps the Fast Connect rule needs some review to address the specific issue of extensible capabilities. Have video endpoints already encountered this problem? Do any video endpoint implementors have any relevent comments here? Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 23:35 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I've only seen this problem with fax. To answer your last question, I've only seen T.38 use this kind of version tag. However, V.150.1 also has versioning information as part of the object identifier that identifies the capability. This will be interesting to see if we introduce the same kind of problem there. In general, it's just not good to advertise the version through an OLC... it's better to perform a full caps exchange. The trouble is that modem and (to some extent) fax timings are such that we must open channels ASAP... before a caps exchange. (Actually, we could transmit the termcap set in the Setup message, but few devices support that.) We have had non-compatible payload specifications before and we resolved that by adding new code points. However, we've been trying to avoid that. Even so, we could do it again... it's just less desirable. I had another idea. What we could do is, within the t38faxProtocol SEQUENCE, we could indicate which syntax is to be used. Older devices would not see this field and would not decode it. So, when the reply is re-encoded, it would not be present. So, even if the version was set to "2", the "Syntax2002" field, say, would not be present. This would mean that the 1998 syntax has to be used. A newer endpoint would see the field and would properly re-encode it in the reply. This is a bit of a kludge and works only because of the way the ASN.1 encoding/decoding works with every device I've seen. Another solution to the problem might be to require that endpoint use H.245 tunneling and to advertise their capabilities in the Setup message. That could allow us to avoid this problem entirely. I'm just not sure how excited people would be to be forced to use H.245 tunneling every time they use fax, modem, or text relay. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'Paul <mailto:paulej@packetizer.com> E. Jones' ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> ; tsg16q14(a)itu.int <mailto:tsg16q14@itu.int> Sent: Wednesday, September 10, 2003 12:34 PM Subject: RE: H.323 Fast Connect and Versioning Paul, I wrote the first part of this email and then reread yours - I was bogged down in the fax issue but I think you are actually raising a wider issue aren't you? See part 2 below. -------------------------- Part 1 I don't believe that 5 versions of T38 would result in 5 offered channels. The need for the different capability is due to the fact that what you are offering is a payload that is encoded in a different and incompatible way. ie its a bit like offering G.729 and the sending packets encoded according to G.723.1, they both represent speech but they are not going to be played out properly. The single extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is backwards incompatible. The problem only exists for endpoints that only know about the 1998 ASN.1 and are unaware of the incompatibility - it is important that they do not think they can accept the offered channel. Once an endpoint is aware of the problem (ie it knows about the 2002 ASN.1) then it can handle versions >= V2 (as well as V0 and V1). Of course, this does assume that a similar incompatibilty does not creep into the payload ASN.1 in future versions - but that's down to careful work in the standard development and editing stage. I still think adding t38faxV2 (say) to DataApplicationCapability and DataApplicationMode is the simplest solution [ t38faxV2 would use the same definitions for t38FaxProtocol and t38FaxProfile - its only the payload that has changed ]. This protects the existing T.38 implementations and avoids the need to break the rule about modifying Fast Connect proposals. The change in the T.38 payload ASN.1 breaks the fundamental backwards compatibility that ASN.1 is supposed to guarantee and thus whatever the final solution there has to be an element of a hack involved - I think that this change would isolate the change and protect the rest of the standard. -------------------------- Part 2 The versioning issue applies to any form of payload, voice/video/fax/whatever. The problem is still going to exist in early versions of endpoints that don't understand the consequence of accepting versions that they do not understand fully. If a new version of a codec's payload is not backwards compatible then I would assert that it is a new codec and must be signalled as a different capability. The issue of multiple variations already exists anyway although not (to my knowledge) with version numbers. Endpoints already offer multiple packet sizes for exactly the reason that you are not supposed to alter the Fast Connect proposal. What happens when somebody starts to offer g729Extensions and has to offer all the combinations of Annexes because they don't know what the other end can use ( I make that 64 proposals in each direction without adding further annexes! )? I don't see that relaxing the rule about modifying the version in a Fast Connect channel will help resolve the problem of having to offer multiple proposals. You either have to allow *anything* to be modified or stick to the current rule. Exceptions allowing certain fields to be modified just makes life much more difficult and confusing. T.38 is the only codec I am aware of that actually uses a version number in this manner. Are there any others? Why was it introduced in T.38? Perhaps this is a lesson for the future about the value of introducing of such a field in other codecs. Peter -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 10 September 2003 16:01 To: Peter Price; itu-sg16(a)external.cisco.com; tsg16q14(a)itu.int Subject: Re: H.323 Fast Connect and Versioning Peter, I think you're on the right track. We could avoid ASN.1 changes by introducing the new capability as a generic data capability, but a new capability is required here, I think. The problem, as I see it, is that when we use Fast Connect, we can't alert the calling side as to what version the called side actually supports. This suggests that if we have 5 versions of T.38, the calling side would have to propose a channel for each version independently. That's horrible. It's only complicated further by the fact that T.38 may not be signaled by itself-- it might be part of audio proposals that also include modem, text over IP, VBD, or other media. It might even be that there are several versions of the modem (V.150.1) protocol advertised. I think the only real solution to this problem is to allow the Fast Connect proposals to be altered by the called endpoint such that they can change the version number.. and nothing else. H.323 has an explicit statement that says that the proposals can't be modified before returning them, but perhaps this simple exception might resolve these issues. I think without such, it's going to be terrible complicated. Paul ----- Original Message ----- From: Peter Price <mailto:PeterP@vegastream.com> To: 'paulej(a)PACKETIZER.COM' <mailto:'paulej(a)PACKETIZER.COM'> ; itu-sg16(a)external.cisco.com <mailto:itu-sg16@external.cisco.com> Sent: Wednesday, September 10, 2003 3:23 AM Subject: RE: H.323 Fast Connect and Versioning Paul wrote "Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message." Unfortunately this won't work - although typically the called endpoint will provide the first IFP (Probably a CED) this doesn't work when you poll for a fax - in that case the calling endpoint will probably want to send the first IFP. The only way I can see out of this is to add a new data application (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1. t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 - and future carefully checked modifications ;-). Now there's no problem, a 2002 aware endpoint can offer both versions and a 1998 aware endpoint can only accept the ASN.1 it understands. Pete Price Vegastream Limited -----Original Message----- From: paulej(a)PACKETIZER.COM [mailto:paulej@PACKETIZER.COM] Sent: 09 September 2003 20:32 To: itu-sg16(a)external.cisco.com Subject: H.323 Fast Connect and Versioning Folks, Today, I was exchanging e-mail with somebody over the fax version number issue and the different syntax that is used (1998 vs 2002). If we open H.245 and exchange a full set of capabilities, and H.323 endpoint could determine the version supported by the other side and open a channel supporting that particular version. However, I don't think any text is explicitly clear on that. Another scenario-- and one I have more trouble with-- is Fast Connect. If a calling endpoint populates the fastStart element with "version 2" proposals, for example, the called side (say, a version 0 device) might accept the proposal and return the response. However, it is not allowed to modify the version field. The reason is that Fast Connect proposals are not ordered in a way such that replies must be ordered the same way. Rather, the calling device determines which proposals are accepted based on characteristics of the proposals returned (e.g., codec type, samples per packet, or other information). In some cases, a calling endpoint will actually not try to "match" the proposal returned, but just accept it as a proposal and run with it. The problem is that if a calling device proposes version 2 and the called device returns version 2 (but is actually a v0 device), then the wrong syntax will be transmitted on the wire. Thus, the text needs to state somewhere one of these options (or something similar): 1. The calling device must offer a proposal for each version it wants to potentially use and the called device must accept the first proposal it can accept (in order of the proposals) and the called device must not accept any proposal for a version it does not support 2. The calling device must wait for capability exchange to complete to determine the actual supported version of the other device Alternatively, we could make an allowance for the endpoint to change the version number in the Fast Connect proposal, but I don't think that's a good idea, as it would quite possibly break interoperability with some devices. What would a version 0 device do today if it received a Fast Connect proposal advertising version 2? Would it accept it? I suspect so and I'm afraid that we might have some interop problems regardless of the direction we go. Perhaps we can require the calling device to not transmit any data until it receives at least one IFP packet from the called side and determines the ASN.1 version used to encode the message. As much as we can push onto the shoulders of a v2 device, the better, as I don't think we have any real deployments in the field (yet)... might be wrong, but I think it would be a far less significant impact on that side. I'm open to suggestions. Perhaps this issue is even addressed and I've simply overlooked it. Thanks, Paul

1 0