H.323 Fast Connect and Versioning

[paulej at PACKETIZER.COM]

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 at PACKETIZER.COM' ; itu-sg16 at 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 at PACKETIZER.COM [mailto:paulej at PACKETIZER.COM]
    Sent: 09 September 2003 20:32
    To: itu-sg16 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20030910/e840c631/attachment-0004.html>