[asterisk-users] Asterisk 1.6.1.13 and T.38 faxing

[Steve Underwood]

On 02/03/2010 03:14 AM, Kevin P. Fleming wrote:
> Steve Underwood wrote:
>
>    
>> I wonder why Asterisk would say:
>>
>> X-asterisk-Info: SIP re-invite (External RTP bridge)
>> Content-Type: application/sdp
>> Content-Length: 344
>>
>> v=0
>> o=root 44350963 44350964 IN IP4 10.153.66.146
>> s=Asterisk PBX 1.6.1.13
>> c=IN IP4 10.153.66.146
>> t=0 0
>> m=image 4819 udptl t38
>> a=T38FaxVersion:0
>> a=T38MaxBitRate:14400
>> a=T38FaxFillBitRemoval
>> a=T38FaxTranscodingMMR
>> a=T38FaxTranscodingJBIG
>> a=T38FaxRateManagement:transferredTCF
>> a=T38FaxMaxDatagram:1400
>> a=T38FaxUdpEC:t38UDPRedundancy
>>
>> I'm pretty sure it doesn't support T38FaxTranscodingMMR or
>> T38FaxTranscodingJBIG, so they should not be there. Perhaps more
>> relevant to you, though, is why is * saying "(External RTP bridge)".
>> Does it really mean it?
>>      
> That latter part is just a small bug in chan_sip; any re-INVITE sent on
> a call gets that tag, because originally direct media path (external
> bridging) was the only means to generate re-INVITE requests. Now that
> T.38 can do it as well, the code hasn't been changed to properly tag them.
>
> As far as the T.38 parameters go, those are under control of the
> application that caused the re-INVITE (or the bridged channel, if this
> is a passthrough situation). If he's using app_fax/spandsp, I believe we
> currently have app_fax configured to offer TranscodingMMR and
> TranscodingJBIG because spandsp supports those modes. The Fax for
> Asterisk product does not, so re-INVITEs generated by that
> implementation would not include those options.
>    
Spandsp doesn't support those features. I don't know anything which 
does. It seems they can only be used with TCP. Spandsp does support

T38FaxFillBitRemoval

which the FAX for Asterisk package does not (according to Commetrex).

Steve