revised version of TF21 on gcl incoming area
RT fax interested parties:
Please find in the GCL incoming area TF21-revised-3-ww6.doc which is the current revision of both a
proposed Annex A for T.ifax2 and proposed Annex IV for H.323
The ideas of TF21 have been generally although not finally accepted by the meeting, with the idea that call realated messages will be removed from T.ifax2 and replaced by a new Annex, to be determined at the next SG8 meeting in June 98, that is H.323 compatible. My proposal is to seek to determine Annx IV of H.323 at our January meeting. Note that T.ifax2 is already determined, but the white has not yet been issued.
Comments welcome.
This will all play with fast start issues as interoperability hinges on using fast start procedures.
Dale Skran Rapporteur Q13 WP2 SG16
Dale,
Regarding the revision of TF21:
As you undoubtedly realize, but not mentioned in TF21, a major reason for specifying the fast switch capability is for calls that are between PSTN devices and gatewayed via an IP network. In this environment, a call can switch between voice and fax and back.
I'd like a little more clarification on the Fast-switch-capabity-from-Voice-coder-UDP-to-fax-coder-UDP mode that you define in TF21. Is the intent here that the change includes the encapsulation of the Fax data within RTP? This seems the most reasonable mechanism since it allows the maintenance of accurate timing and sequence when switching between modes. If the change between modes is in-band without any logical channel signalling, how would the RTP payload type of the fax packets be indicated, since it would be assigned as a dynamic payload type?
I have a similar question with regard to the Real-Time-Fax-over-UDP mode. Does it imply encapsulation within RTP as well? If you are using normal H.245 logical channel operations to change from voice to fax mode, particularly the replacementFor procedure, the mode change, while signalled in advance, is actually indicated when the RTP Payload type changes.
Since, in the PSTN<->IP<->PSTN gateway environmemt, it may not be possible to know whether or not the call will contain fax data until well after the end-to-end connection is established, it should be allowable for an endpoint to advertise its fax capabilities as well as voice capabilities and still complete the call even if the other end does not support a fax capability.
steve magnell Dialogic Corporation
participants (2)
-
Dale L. Skran -
Steven Magnell