Skip to content
Snippets Groups Projects
  • Kevin P. Fleming's avatar
    0a6e06c7
    Rework of T.38 negotiation and UDPTL API to address interoperability problems · 0a6e06c7
    Kevin P. Fleming authored
    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: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
    0a6e06c7
    History
    Rework of T.38 negotiation and UDPTL API to address interoperability problems
    Kevin P. Fleming authored
    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: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3