[asterisk-dev] [Code Review] Rework of T.38 negotiation and UDPTL API to address interoperability problems

[Bryant Zimmerman]

Kevin

How can I apply your patches to our test env. We rely on T.38 on our 
network and have had issues with some of the items you listed.

Thanks
Bryant

----------------------------------------

From: "Kevin Fleming" <kpfleming at digium.com>
Sent: Monday, July 13, 2009 7:48 PM
To: "Kevin Fleming" <kpfleming at digium.com>, "Asterisk Developers" 
<asterisk-dev at lists.digium.com>
Subject: [asterisk-dev] [Code Review] Rework of T.38 negotiation and UDPTL 
API to address interoperability problems 

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/310/
-----------------------------------------------------------

Review request for Asterisk Developers.

Summary
-------

Over the past couple of months, a number of issues with Asterisk 
negotiating (and successfully completing) T.38 sessions with various 
endpoints have been found. This patch attempts to address many of them, 
primarily focused around ensuring that the endpoints' MaxDatagram size is 
honored, and in addition by ensuring that T.38 session parameter 
negotiation is performed correctly according to the ITU T.38 
Recommendation.

The major changes here are:

1) T.38 applications in Asterisk (app_fax) only generate/receive IFP 
packets, they do not ever work with UDPTL packets. As a result of this, 
they cannot be allowed to generate packets that would overflow the other 
endpoints' MaxDatagram size after the UDPTL stack adds any error correction 
information. With this patch, the application is told the maximum *IFP* 
size it can generate, based on a calculation using the far end MaxDatagram 
size and the active error correction mode on the T.38 session. The same is 
true for sending *our* MaxDatagram size to the remote endpoint; it is 
computed from the value that the application says it can accept (for a 
single IFP packet) combined with the active error correction mode.

2) All treatment of T.38 session parameters as 'capabilities' in chan_sip 
has been removed; these parameters are not at all like audio/video stream 
capabilities. There are strict rules to follow for computing an answer to a 
T.38 offer, and chan_sip now follows those rules, using the desired 
parameters from the application (or channel) that wants to accept the T.38 
negotiation.

3) chan_sip now stores and forwards ast_control_t38_parameters structures 
for tracking 'our' and 'their' T.38 session parameters; this greatly 
simplifies negotiation, especially for pass-through calls.

4) Since T.38 negotiation without specifying parameters or receiving the 
final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 
control frame has been removed. A note will be added to UPGRADE.txt about 
this removal, since any out-of-tree applications that use it will no longer 
function properly until they are upgraded to use 
AST_CONTROL_T38_PARAMETERS.

The intent is for this patch to applied/backported to all active 1.6.x 
branches; the T.38 negotiation and interop problems that exist today are 
fundamental enough that all the branches deserve the fixes.

Diffs
-----

/trunk/apps/app_fax.c 206279 
/trunk/channels/chan_sip.c 206279 
/trunk/include/asterisk/frame.h 206279 
/trunk/include/asterisk/udptl.h 206279 
/trunk/main/channel.c 206279 
/trunk/main/frame.c 206279 
/trunk/main/rtp_engine.c 206279 
/trunk/main/udptl.c 206279 

Diff: https://reviewboard.asterisk.org/r/310/diff

Testing
-------

Tested sending and receiving FAXes over T.38 using app_fax (SendFAX and 
ReceiveFAX), along with T.38 passthrough.

Thanks,

Kevin

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090713/f90ec2ae/attachment.htm