Merged revisions 208464 via svnmerge from

https://origsvn.digium.com/svn/asterisk/trunk

........
  r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines
  
  Rework of T.38 negotiation and UDPTL API to address interoperability problems
  
  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 has been 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.
  
  Review: https://reviewboard.asterisk.org/r/310/
........


git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@208468 f38db490-d61c-443f-a65b-d21fe96a405b

1 files changed, 5 insertions, 4 deletions

diff --git a/main/channel.c b/main/channel.c
index 7ab59badd..3a0e53c1a 100644
--- a/main/channel.c
+++ b/main/channel.c
@@ -3050,9 +3050,9 @@ static int attribute_const is_visible_indication(enum ast_control_frame_type con
 	case AST_CONTROL_TAKEOFFHOOK:
 	case AST_CONTROL_ANSWER:
 	case AST_CONTROL_HANGUP:
-	case AST_CONTROL_T38:
 	case AST_CONTROL_T38_PARAMETERS:
-		return 0;
+	case _XXX_AST_CONTROL_T38:
+		break;
 
 	case AST_CONTROL_CONGESTION:
 	case AST_CONTROL_BUSY:
@@ -3112,7 +3112,9 @@ int ast_indicate_data(struct ast_channel *chan, int _condition,
 
 	/* Handle conditions that we have tones for. */
 	switch (condition) {
-	case AST_CONTROL_T38:
+	case _XXX_AST_CONTROL_T38:
+		/* deprecated T.38 control frame */
+		return -1;
 	case AST_CONTROL_T38_PARAMETERS:
 		/* there is no way to provide 'default' behavior for these
 		 * control frames, so we need to return failure, but there
@@ -4765,7 +4767,6 @@ static enum ast_bridge_result ast_generic_bridge(struct ast_channel *c0, struct
 			case AST_CONTROL_UNHOLD:
 			case AST_CONTROL_VIDUPDATE:
 			case AST_CONTROL_SRCUPDATE:
-			case AST_CONTROL_T38:
 			case AST_CONTROL_T38_PARAMETERS:
 				ast_indicate_data(other, f->subclass, f->data, f->datalen);
 				if (jb_in_use) {