Paul, Thanks for your comments. (The other mails and other parts of Paul's mail are cut and snipped.)

...

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).

Yes, I understand.

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.

Are you saying it is the old verion 2? If so, right. But, according to the results of May meeting, The "new" version 2 must use 2002 ASN.1 syntax. Anyway, there may be a problem in version 2.

...

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?

I thought it would happen from the conversion among us. I do not understand well. One of my understanding is that the version 1 machine is not aware of our syntax issue and it could accept any Setup and return Connect irrespective of the version. Am I right?

...

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.

OK. That's my misunderstanding.

...

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?

Maybe, both :-< Excuse me for a basic question. Why are there issues in Fast Connect only? The 2002 ASN.1 syntax is for t30-data. Before V.21 signal starts, i.e. during CNG and CED exchange, I do not believe there are issues. If we use Fast Connect and V.21 signals are exchanged during Fast Connect, it would be a problem. Is this one of the problems?

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.

I do not know H.460.6, either. If it can be compatibile with the current implementation, that's ok. But, the support of new recommendation is burden to implementers. Anyway, we need to do for January meeting. Regards, -- Hiroshi Tamura