Merged revisions 254450 via svnmerge from

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

........
  r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines
  
  Improve handling of T.38 re-INVITEs that arrive before a T.38-capable
  application is executing on a channel.
  
  This patch addresses an issue found during working with end-users
  using res_fax. If an incoming call is answered in the dialplan, or
  jumps to the 'fax' extension due to reception of a CNG tone (with
  faxdetect enabled), and then the remote endpoint sends a T.38
  re-INVITE, it is possible for the channel's T.38 state to be
  'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
  even if the application wants to use T.38, it can't respond to the
  peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
  control frame that chan_sip sent originally has been lost, and the
  application needs the content of that frame to be able to formulate a
  reply.
  
  This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
  AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
  will re-send the original control frame (with
  AST_T38_REQUEST_NEGOTIATE as the request type), and the application
  can respond as normal. If this occurs within the five second timeout
  in chan_sip, the automatic cancellation of the peer reinvite will be
  stopped, and the application will 'own' the negotiation process from
  that point onwards.
  
  This also improves the code path in chan_sip to allow sip_indicate(),
  when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
  non-zero response, which should have been in place before since the
  control frame *can* fail to be processed properly. It also modifies
  ast_indicate() to return whatever result the channel driver returned
  for this control frame, rather than converting all non-zero results
  into '-1'. Finally, the new request type intentionally returns a
  positive value, so that an application that sends
  AST_T38_REQUEST_PARMS can know for certain whether the channel driver
  accepted it and will be replying with a control frame of its own, or
  whether it was ignored (if the sip_indicate()/ast_indicate() path had
  properly supported failure responses before, this would not be
  necessary).
  
  This patch also modifies res_fax to take advantage of the new request.
  
  In addition, this patch makes sip_t38_abort() actually lock the
  private structure before doing its work... bad programmer, no donut.
  
  This patch also enhances chan_sip's 'faxdetect' support to allow
  triggering on T.38 re-INVITEs received as well as CNG tone detection.
  
  Review: https://reviewboard.asterisk.org/r/556/
........


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

1 files changed, 7 insertions, 3 deletions

diff --git a/configs/sip.conf.sample b/configs/sip.conf.sample
index 760b1fa53..291f86e8d 100644
--- a/configs/sip.conf.sample
+++ b/configs/sip.conf.sample
@@ -471,9 +471,13 @@ srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
 ;                                       ; send 400 byte T.38 FAX packets to it.
 ;
 ; FAX detection will cause the SIP channel to jump to the 'fax' extension (if it exists)
-; when a CNG tone is detected on an incoming call.
-; 
-; faxdetect = yes              ; Default false	
+; based one or more events being detected. The events that can be detected are an incoming
+; CNG tone or an incoming T.38 re-INVITE request.
+;
+; faxdetect = yes		; Default 'no', 'yes' enables both CNG and T.38 detection
+; faxdetect = cng		; Enables only CNG detection
+; faxdetect = t38		; Enables only T.38 detection
+; faxdetect = both		; Enables both CNG and T.38 detection (same as 'yes')
 ;
 ;----------------------------------------- OUTBOUND SIP REGISTRATIONS  ------------------------
 ; Asterisk can register as a SIP user agent to a SIP proxy (provider)