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

[Kevin P. Fleming]

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org