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: [email protected] Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
