Summary:ASTERISK-11519: [patch] T38 passthru broken in trunk
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2008-02-26 16:26:29.000-0600Date Closed:2008-02-27 09:28:39.000-0600
Versions:Frequency of
Environment:Attachments:( 0) v1-12078.patch
( 1) v1-12078-2.patch
Description:People are reporting broken T38 passthru in the trunk.

It appears that my patch for issue 11630 while fixes the problem desctibed in the issue introduces new one. To remind the issue 11630 was about t38state receiving wrong value when 200 OK for our T38 reinvite is received. The problem is that the passthru code depends on that wrong value.

Attached patch fixes the problem.


Patch tested in two scenarios - in one Asterisk terminates T38 fax (ReceiveFax) and in another, Asterisk just passthru the T38 to another Asterisk which terminates with ReceiveFax.
Comments:By: Dmitry Andrianov (dimas) 2008-02-26 19:03:04.000-0600

Almost forgot. It looks like when the new AST_CONTROL_T38 frame is read when in the native bridging, it aborts the loop and following output on the console is seen:

[Feb 17 21:41:10] DEBUG[12822]: rtp.c:3391 bridge_native_loop: Got a FRAME_CONTROL (19) frame on channel SIP/2000-08c9fb18
[Feb 17 21:41:10] DEBUG[12822]: channel.c:4418 ast_channel_bridge: Returning from native bridge, channels: SIP/2000-08c9fb18, SIP/lab3-08cb44e0

However next line says
   -- Native bridging SIP/2000-08c9fb18 and SIP/lab3-08cb44e0

and things actually do work. But if it is good idea to avoid this message completely, than the secons pacth (v1-12078-2.patch) must be applied too.

By: Digium Subversion (svnbot) 2008-02-27 09:27:45.000-0600

Repository: asterisk
Revision: 104533

U   trunk/channels/chan_sip.c
U   trunk/main/rtp.c

r104533 | file | 2008-02-27 09:27:39 -0600 (Wed, 27 Feb 2008) | 8 lines

Fix T38 passthrough regression introduced by state changes.
(closes issue ASTERISK-11519)
Reported by: dimas
     v1-12078.patch uploaded by dimas (license 88)
(closes issue ASTERISK-11515)
Reported by: Ivan