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:
- Add a new "syntax2002" field
- 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 -----
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
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 -----
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
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 -----
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
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):
- 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
- 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