-----Ursprüngliche
Nachricht-----
Von: paulej@PACKETIZER.COM
[mailto:paulej@PACKETIZER.COM]
Gesendet am: Freitag, 12. September
2003 22:57
An: itu-sg16@external.cisco.com
Betreff: 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:
- 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