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
Hiroshi Tamura