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

Steve Underwood steveu at coppice.org
Tue Feb 2 13:43:10 CST 2010


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





More information about the asterisk-users mailing list