[Asterisk-Dev] T.38 pass-through / T.38 support

[Steve Underwood]

Matthew Boehm wrote:

>Steve Underwood wrote:
>  
>
>>They must be bypassing * then. * has no way to pass-through a UDPTL
>>stream right now. I don't see how it would even bypass a T.38 stream,
>>though. It lacks the ability to negotiate one.
>>    
>>
>
>I know you find it hard to believe Steve, but I guarantee you this is what
>happens:
>
>Caller on PSTN dials ATA fax. Call is routed to AS5300 over PRI. Call
>becomes T38. 5300 sends call to Asterisk and on to ATA via SIP. The warning
>messages about UDPTL t38 that I said previously display during the transfer
>of the fax. Call completes and fax looks great.
>
>Or
>
>Call originates from ATA. Asterisk sends call to 5300. 5300 says its T38.
>The 5300 will, depending on if local or LD call, terminate either PRI to
>PSTN or to carrier via H323. Call completes and fax looks great.
>
>All of it goes thru asterisk at some point.
>  
>
I certainly don't believe divine intervention carries your bits. :-)

At the beginning of this thread you said you get:

Jun  3 10:20:05 WARNING[14277]: chan_sip.c:3063 process_sdp: Unknown SDP media type in offer: image 49170 udptl t38

and I assume from the way you said it, that you don't get other complaints. The relevent other complaint in this context would be that T.38 over RTP is not supported by *. This seems probable. I have not seen an ATA so far that supports T.38 over RTP. They only do UDPTL (and usually with so many bugs they are useless). Asterisk does not yet have a UDPTL transport (at least what is in CVS doesn't. I have one here, but its not yet read to go into CVS). There ain't no way UDPTL is passing through *. What I assume happens is the ATA calls into *. * gives the above message. A G.711 call goes through to the Cisco. A re-invite connects those 2 directly, bypassing *. They chat amongst themselves, renegotiate, and talk UDPTL directly.

Can you tell me what ATA you use? If it has a T.38 that really works, I'd really like to know what it is.

Regards,
Steve