SIP Forum Fax Over IP Task Group Problem Statement

T.38: Problems related to SIP/SDP Negotiation

While the T.38 protocol, approved by the ITU-T in 1998, was designed to allow fa !achines and co!p"ter-based fa to carry forward in a transitioning co!!"nications infrastr"ct"re of both I#- and T$%-based telephony, in &''9 there are eno"gh proble!s and conf"sion a!ong vendors, enterprises, and service providers to significantly slow the "se of I# as a real-ti!e fa transport. The iss"es s"rro"nding I#-based fa in general and the "se of T.38 !a(e it diffic"lt for "sers to deter!ine if T.38 can or will wor( reliably and th"s offer an alternative to traditional T$%-based fa transport. To address these proble!s and offer sol"tions, the )I# *or"! has chartered the *oI# Tas( +ro"p ,T+-. The charter of the )I# *or"! *oI# tas( gro"p is to investigate ongoing iss"es with the deploy!ent of fa services, specifically ITU-T T.38, in )I# networ(s. )I# networ(s cannot ade."ately replace analog and digital #)T/ in enterprises "nless essential services s"ch as fa are acco!!odated. This doc"!ent details a n"!ber of )$# offer0answer interoperability iss"es fo"nd while i!ple!enting and connecting T.38 co!pliant endpoints together, pri!arily over the )I# signaling !echanis!. 1owever, !any of the iss"es presented here are not specific to )I# or )$#, b"t are in fact proble!s that wo"ld occ"r over any T.38-capable signaling !echanis!.

Definitions and References

1. ITU Recommendation T.38 (T38 In this doc"!ent, references to the ITU T.38 2eco!!endation are specific to the 3pril, &''4 p"blished version. !. 3. Internet "acsimile Transfer (I"T 3s defined in T38, the !ethod of transferring facsi!ile data over the Internet. Internet "acsimile Protocol (I"P 3s defined in T38, the protocol "sed to i!ple!ent I*T by carrying ITU T.3' facsi!ile protocol signaling and data over an Internet #rotocol connection. #. '. Part$ % or &alling Part$ The endpoint that initiated the call in ."estion. Part$ ( or &alled Part$ The endpoint that received the call in ."estion.

Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

). *mitting +ate,a$ 3s defined in T38, the I*# endpoint which initiates I*T service for a calling facsi!ile endpoint. In typical networ(s, this will be a !edia gateway or si!ilar device. -. Recei.ing +ate,a$ 3s defined in T38, the I*# endpoint which accepts an I*T service connection re."est fro! an 5!itting +ateway and provides I*T service to an answering facsi!ile endpoint. In typical networ(s, this will be a !edia gateway or si!ilar device. 8. Internet/%,are "%0 (I%" 3 facsi!ile endpoint that can co!!"nicate "sing the T.38 I*T directly, witho"t the need of a !edia gateway. I3*s were first defined in T38 3!end!ent 3.

Problems
While the following is not an all-incl"sive list, it presents the highest-priority iss"es as deter!ined by the Tas( +ro"p. 1. Triggering of T.38 s,itc1o.er #roble!s T38 does not indicate which party ,#arty 3 or #arty 6- is responsible for detecting that a *37 trans!ission is being atte!pted and initiating the switch fro! a"dio !ode to T.38 !ode. In practice, this res"lts in so!e co!!on scenarios8 3 2eceiving +ateway !ay initiate T.38 after detecting 95$03/) tones generated by the #arty 6 endpoint. 3 2eceiving +ateway !ay initiate T.38 after detecting the :.&1 1$;9 flags ,prea!blegenerated by the party 6 endpoint. 3 2eceiving +ateway !ay initiate T.38 after detecting 9/+ tone generated by the #arty 3 5ndpoint. 3n 5!itting +ateway !ay initiate T.38 after detecting 9/+ tone generated by the #arty 3 endpoint.

In so!e cases, gateways !ay atte!pt to detect tones generated by the far endpoint, which !ay be "nreliable if the a"dio connection between the endpoints is "sing a highly co!pressed voice codec. While it is generally accepted that the 2eceiving +ateway sho"ld initiate the switch to T.38, and it sho"ld only do this after detecting the :.&1 1$;9 flags generated by the endpoint it services ,to ens"re that the answering device is in fact a facsi!ile endpoint, and not a data !ode! or other device that !ight also generate 95$03/) tones-, in practice this is not the case, and act"al devices !ay act in any of the fashions listed above. This can easily res"lt in <glare<, where both gateways atte!pt to switch to T.38 ,nearlyCopyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

si!"ltaneo"sly, or a co!plete lac( of T.38 switchover if the detection !ethod in "se is not ade."ately able to detect the far endpoint<s generated tones. In a <glare< sit"ation, if the gateways do not properly i!ple!ent bac(off proced"res as defined in 2*9 3&=1, the call will li(ely fail. !. T.38 re23ested on initial IN4IT* #roble!s I3* devices and so!e gateways !ay send an initial I/:IT5 containing a T.38 !edia strea! offer. In !ost cases, this !edia strea! will be !ar(ed as <inactive<, and will be acco!panied by an active a"dio strea! offer. In other cases, no a"dio strea! offer will be present at all ,pri!arily I3* devices-. If no a"dio strea! is present, a receiving endpoint !ay re>ect the I/:IT5 beca"se it cannot deter!ine whether T.38 will be s"pported by the session<s event"al destination "ntil after so!e call ro"ting processes have co!pleted. 3. T.38 session 5arameters c1anged d3ring T.36 session #roble!s )o!e endpoints will send re-I/:IT5 !essages containing !odified T.38 session para!eters in their )$# offer after the endpoints have previo"sly agreed on T.38 session para!eters and the T.38 session has beg"n. If the receiver of this offer accepts it, the i!plication is that the active T.38 session<s para!eters will be !odified to confor! to the new offer, which is "nli(ely to be possible since the session is already active. If the receiver of the offer re>ects it, the sender of the offer is li(ely to drop the call. #. 7inim3m/ma8im3m red3ndanc$ I"Ps in UDPT9 frames #roble!s T38 doc"!ents an error correction sche!e ,referred to as <error protection<- that involves sending red"ndant copies of previo"sly-trans!itted I*# !essages in s"bse."ent U$#T; fra!es. This affords the receiver the opport"nity to recover fra!es lost in transit. Indication of the s"pport of this !ode is !ade by setting the T38*a Udp59 para!eter to <t38U$#2ed"ndancy?. 1owever, T38 !a(es no reco!!endation abo"t the n"!ber of red"ndancy !essages that sho"ld be incl"ded in a U$#T; pac(et, nor does it have any lang"age to ta(e into acco"nt the red"ndancy !essages when co!p"ting the !a i!"! I*# si@e that can be trans!itted to the receiving endpoint ,based on its reported T38*a %a 6"ffer and0or T38*a %a $atagra! para!eters-. '. S355ression of a3dio d3ring T.38 s,itc1o.er #roble!s When a 2eceiving +ateway senses that the endpoint it is servicing is atte!pting to initiate a facsi!ile connection, and the gateway intends to switch to T.38 to service that connection, it !ay not s"ppress the a"dio strea! fro! the endpoint towards the 5!itting +ateway. If it does not do so, the endpoints will atte!pt to negotiate a T.3' facsi!ile connection over the a"dio strea! while the T.38 session is being established in the
Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

signaling path. While the T.38 session negotiation process, "nder nor!al circ"!stances, sho"ld occ"r rapidly eno"gh to prevent the endpoints fro! e changing $I) and $9), if this does occ"r, then when the T.38 session begins the facsi!ile connection will have progressed too far to be recovered and it will fail. ). T.38 Session Parameter: T38"a84ersion #roble!s This para!eter appears clear and si!ple at first sight, b"t recent disc"ssions show that so!e people try to read !ore into this para!eter than they sho"ld. )o!e people interpret the version as !ore of a f"nctionality level indicator, so 3 i!plies the T.38 device s"pports :.3A. T38 does not appear to s"pport this interpretation, tho"gh it offers no clear way for a T.38 device to assess if a re!ote T.38 device s"pports :.3A ,tho"gh T38%a 6it2ate !ay infer it-. Testing if T38*a :ersion is @ero vs non-@ero is a critically i!portant distinction ter!inals need to !a(e, otherwise they can<t interpret the 3)/.1 they receive. I!ple!entations !"st s"pport all versions "p to the one they advertise as T38*a :ersion. If one side says it s"pports "p to version 7, and the other side says it s"pports "p to version B, when B C 7, the co!!"nication will happen both ways in version 7 !ode. That is, the highest version they have in co!!on will be "sed. 3 !issing T38*a :ersion field i!plies version ', and this appears to achieve nat"ral co!patibility with the very oldest i!ple!entations. 5ven today, version ' is still by far the !ost co!!on in "se. %ost T.38 entities s"pport nothing else. -. T.38 Session Parameter: T387a8(itRate #roble!s This para!eter indicates the !a i!"! fa i!age bit rate s"pported by the endpoint. This is an odd way to e press things, as the endpoints vary by which !ode! standards they s"pport, rather than which bit rates. 1owever, in practice the following i!plications see! to wor( o"t DE for all (nown i!ple!entations of T.388 T38%a 6it2ate89='' i!plies :.&9 and :.&4ter s"pport. T38%a 6it2ate81AA'' i!plies :.14, :.&9 and :.&4ter s"pport. T38%a 6it2ate833='' i!plies :.3A, :.14, :.&9 and :.&4ter s"pport. There appears to be so!e conf"sion that this para!eter has so!e bandwidth !anage!ent p"rpose. T38 doesn<t s"pport that. It si!ply says it is the !a i!"! *37 bit rate. The act"al bandwidth in the I# channel !ay vary greatly, depending on ch"n( si@es and the level of red"ndancy0*59 "sed.

Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

8. T.38 Session Parameter: T38"a8"ill(itRemo.al #roble!s This para!eter indicates that it is acceptable for the 5!itting +ateway to re!ove all fill bits fro! a non-59% i!age, beca"se the receiving side will reinsert the appropriate !ini!"! a!o"nt. This see!s clear, tho"gh it is seldo! s"pported. 2e!oving 1''F of the fill bits re."ires deep inspection of the i!age, b"t re!oving C9GF is act"ally a very lightweight processing tas(, and can save so!e worthwhile bandwidth for non-59% calls. The receiving side needs to ad>"st the fill bits, for flow control, so rei!posing a !ini!"! on a bit strea! stripped of fill bits at the sa!e ti!e is a !inor additional tas(. :. T.38 Session Parameter: T38"a8Transcoding77R #roble!s This para!eter indicates the ability to transcode %10%2 fro!0to a facsi!ile endpoint to %%2 data between the T.38 gateways. It is "nclear whether this is s"pposed to wor( only for non-59% trans!ission, or for non-59% and 59%. )ince !ost 59% trans!ission "ses T.= or H6I+ encoding, it !ay not be a big iss"e, b"t it isn<t properly specified. It is easy to i!ple!ent this for non-59% fa ing, b"t it wo"ld be i!practicable for 59%. This (ind of transcoding does have the potential to c"t the bandwidth re."ire!ent between the T.38 gateways significantly. 1owever, nearly all fa !achines are able to do %%2 co!pression these days, so !achines that don<t "se it do so by config"ration choice. It is ."estionable, therefore, whether the T.38 gateways sho"ld override s"ch "ser choices. 16. T.38 Session Parameter: T38"a8Transcoding;(I+ #roble!s It see!s i!possible to "se the T38*a TranscodingH6I+ option, as T38 specifies it so vag"ely. It is s"pposed to indicate the ability to send H6I+ data between T.38 gateways, when the facsi!ile endpoints connected to those gateways are "sing so!e other ,pres"!ably poorer- bi-level co!pression. 1owever, T38 says nothing abo"t how this is s"pposed to wor(. H6I+ can only be "sed with g"aranteed-delivery transport ,s"ch as T9#-. 11. T.38 Session Parameter: T38"a87a8(3ffer #roble!s This para!eter tells each end how !"ch b"ffer space the other end has. The val"es for the two directions are co!pletely independent. 1owever, the e act !eaning of Ib"ffer spaceI is not clarified in T38. Is it received U$#T;02T#0T#ET pac(etsJ Is it I*# !essagesJ Is it the data e tracted fro! I*# !essagesJ 3lso, the e act playo"t stat"s of the far end is never (nown, as it needs to ti!e vario"s things for itself. T38 gives no g"idance abo"t the ti!ing of the start of data relative to the carrier start indicators, which !a(es this b"ffer iss"e ."ite serio"s. It is never possible to deter!ine e actly how !"ch !ight be in the far end<s b"ffer. Therefore, this para!eter see!s to be of little practical val"e. %ost T.38
Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

i!ple!entations advertise only a s!all b"ffer, so it is i!portant not to flood the! with data, which co"ld overr"n s"ch a s!all b"ffer. In practice, !ost i!ple!entations >"st see! to avoid sending anything "ntil its ti!e appears to be d"e, and hope for the best. 1!. T.38 Session Parameter: T38"a87a8Datagram #roble!s This para!eter see!s to be interpreted in different ways by different i!ple!entations of T.38. It is tied in with the greatest wea(ness of the T.38 spec right now - the lac( of ade."ate ch"n(ing and ti!ing g"idance. The lac( of this gives the designer of the receiving side only a vag"e idea of what to e pect fro! the sending side, serio"sly d"!bing down what the receiving side can do. It also !ightily conf"ses the designer of the sending side as to what is appropriate to send for !a i!"! co!patibility. T38 table 6.1 says IThis option indicates the !a i!"! si@e of a U$#T; pac(et or the !a i!"! si@e of the payload within an 2T# pac(et that can be accepted by the re!ote device.I T38 $.&.1.3.1 says IThe !a i!"! si@e of the payload within an 2T# pac(et that can be accepted by the re!ote device.I T38 $.&.3.G says IThis para!eter signals the largest acceptable datagra! for the offering endpoint and the answering endpoint ,i.e. the !a i!"! si@e of the 2T# payload-. The answering endpoint !ay accept a larger or s!aller datagra! than the offering endpoint. 5ach endpoint sho"ld be considerate of the !a i!"! datagra! si@e of the opposite endpoint.I What e actly is the 2T# payloadJ 6efore adding red"ndancy, or afterJ What abo"t U$#T;J 3 trans!itted 2T# pac(et can obvio"sly be larger than T38*a %a $atagra!, as yo" need to add the fra!ing words to the payload. What happens in the case of U$#T;, where the fra!ing and red"ndancy coalesceJ The !eaning of T38*a %a $atagra! appears to depend on the transport type, which is a rather odd design. In practice it see!s so!e syste!s treat T38*a %a $atagra! as the !a i!"! I*# length, and so!e treat it as the !a i!"! U$#T; length. I infer this, beca"se so!e syste!s "se a n"!ber too s!all for it to be anything b"t the !a i!"! I*# length. 5ither that, or they are not prepared to accept any red"ndancy0*59 data. The n"!ber is also !"ch s!aller than the sa!e bo is prepared to accept for an 2T# pac(et of a"dio, which see!s to i!ply its b"ffers can accept !"ch bigger U$# pac(ets. The only other real g"idance abo"t ch"n(ing see!s to be in T38 4.G. This says the following, in recent versions of T.38, as a s"pposed clarification of earlier wording8 I;i!itation of :.&1 fra!e pac(et si@e To red"ce the gateway processing delay, the "se of s!aller :.&1 fra!e data pac(ets is !ore beneficial for interconnected gateways to fle ibly perfor! >itter b"ffer ad>"st!ent according to the networ( sit"ation and co!patibility of the facsi!ile ter!inal. The !a i!"! :.&1 pac(et si@e shall be 4 bytes, e cept for I3* devices. ;arger :.&1 fra!es shall be sent in !"ltiple pac(ets.I
Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org

SIP Forum Fax Over IP Task Group Problem Statement

What does IThe !a i!"! :.&1 pac(et si@eI !eanJ #res"!ably pac(et here refers to an I*#, b"t is it the total I*# pac(et that sho"ld be KL4 bytes or its :.&1 payloadJ The description see!s to i!ply the total pac(et length, yet its the payload length we are trying to constrain. T38 4.G see!s to conf"se !ore than clarify. In practice a lot of 3T3s are not happy if the :.&1 data I*#s contain !ore than 1 byte of :.&1 data. %ost gateways send one byte per fra!e, and this is reasonably har!less. The annoying ,tho"gh f"lly wor(able- case is sending T.38 fro! a ter!inating T.38 entity. 1ere 1''F of the 1$;9 fra!e<s content is (nown at the instant fra!e trans!ission starts, and the fra!es are always fairly s!all. )till, we end "p sending a !essy and inefficient strea! of pac(ets, with one byte of the 1$;9 fra!e in each, to !a i!i@e co!patibility. 13. 7edia Stream &onfig3ration after T.38 s,itc1o.er from a3dio #roble!s When a call begins as a"dio and then switches to T.38, the !edia strea! config"ration in place after the switchover can vary greatly depending on the endpoint i!ple!entations. There are e a!ples in the field of8 1. The call begins with only an a"dio strea!, and after switchover there is only a T.38 strea!. &. The call begins with an a"dio strea! ,active- and a T.38 strea! ,inactive-M after switchover, the a"dio strea! is inactive and the T.38 strea! Is active. 3. The call begins with only an a"dio strea!, b"t after switchover there are bot1 a"dio and T.38 strea!s, with both !ar(ed as active. In this case, it is highly "nli(ely that the endpoint sending s"ch an offer is act"ally prepared to receive a"dio and T.38 si!"ltaneo"sly. A. The call begins with only an a"dio strea!, b"t after switchover that strea! is converted to T.38 and a ne, a"dio strea! is added to the )$#. While the endpoint !ay in fact be e pecting this to be treated as retaining the e isting a"dio strea! ,active or inactive-, the )$# 2*9s define behavior based on the position that the strea! appears in the offer or answer, and N!oving? the a"dio strea! fro! the first position to the second position in fact !a(es it a new ,different- strea! fro! the one that was in place prior to the switchover. 2eceivers of s"ch an offer will li(ely treat the offer in the way that the offerer intended ,retain the e isting a"dio strea!, possibly changing its active state, and adding a T.38 strea!-, b"t this is only beca"se i!ple!enters have learned to do so to increase interoperability, not beca"se the standards !andate, or even s"ggest, s"ch behavior.

Copyright 2 ! SIP Forum" #ll rights reserve$" %%%"sip&orum"org