Asterisk
  1. Asterisk
  2. ASTERISK-11332

[patch] minimal API to control SIP T38 from application

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Channels/chan_sip/T.38
    • Labels:
      None
    • SVN Revision Number:
      100974
    • Mantis ID:
      11873
    • Regression:
      No

      Description

      file,
      this is minimalistic implementation of API I need for T38 app_fax. I took your idea to control channel T38 switchover with AST_FRAME_CONTROL* messages and added other facilities I have already emailed you about. Please see Additional Infor for detailed information about changes.

      I believe this patch is small enough and can be commited and be improved later if needed. Adoption of this patch would allow me submitting final version of app_fax patch with T38 support which would be good addition to 1.6.

                • ADDITIONAL INFORMATION ******

      1. Added set of AST_CONTROL_T38 frames:

      Request frames. Sent by an application:
      AST_CONTROL_T38_REQUEST_NEGOTIATE - asks channel driver to negotiate T38
      AST_CONTROL_T38_REQUEST_TERMINATE - asks channel driver to switch back to voice. Not really implemented fully.

      Notification frames. Sent by a channel driver:
      AST_CONTROL_T38_NEGOTIATED - T38 negotiated (fax mode)
      AST_CONTROL_T38_TERMINATED - T38 terminated (back to voice)
      AST_CONTROL_T38_REFUSED - T38 refused for some reason (usually rejected by remote end)

      2. Implemented ast_channel_queryoption which was declared but not implemented. Added new option AST_OPTION_T38_STATE which allows reading T38 state of the channel. Added ast_t38state enum to represent these states.

      3. chan_sip fixed to react on these frames / return T38 state when requested

      1. v1-t38-api.patch
        15 kB
        Dmitry Andrianov
      2. v2-t38-api.patch
        17 kB
        Dmitry Andrianov
      3. v3-t38-api.patch
        17 kB
        Dmitry Andrianov
      4. v4-t38-api.patch
        17 kB
        Dmitry Andrianov

        Activity

        Hide
        Joshua Colp added a comment -

        1. I think using a single control frame type with a payload would be better.
        2. The above frame type would need to be added to frame.c for frame debugging (basically spits out a corresponding name).
        3. There are some code style issues, but I can fix those up.
        4. I'm a little bit iffy on using setoption and queryoption. Having the request/response for T38 negotiation be non-blocking concerns me.

        Show
        Joshua Colp added a comment - 1. I think using a single control frame type with a payload would be better. 2. The above frame type would need to be added to frame.c for frame debugging (basically spits out a corresponding name). 3. There are some code style issues, but I can fix those up. 4. I'm a little bit iffy on using setoption and queryoption. Having the request/response for T38 negotiation be non-blocking concerns me.
        Hide
        Dmitry Andrianov added a comment -

        Second attempt attached.
        Hope that #1 and #2 are handled now.

        Regarding the 4 - it was briefly discussed on IRC but I explain here for records:
        For the fax application, non-blocking T38 negotiation is the best way to go. This is because you never know if remote party will accept or reject your offer. Or will it answer at all. Because of this algorithm of the fax receiver is something like:

        • Do the "regular" aka "audio" fax reception (inband)
        • At the same time try negotiating T38 with remote side.
        • If (and only if) remote side agrees on T38, stop audio transmittion and switch to T38. Otherwise continue in the audio mode.

        Also, I do not use setoption at the moment. Only queryoption is used - to get current state of T38 on the channel. This is because fax application does not know in what environment it starts - probably T38 was already negotiated before starting app_fax. After fetching initial status, app_fax does NOT do queryoption repeatedly - insted it gets T38 statys updates from CONTROL frames.

        Show
        Dmitry Andrianov added a comment - Second attempt attached. Hope that #1 and #2 are handled now. Regarding the 4 - it was briefly discussed on IRC but I explain here for records: For the fax application, non-blocking T38 negotiation is the best way to go. This is because you never know if remote party will accept or reject your offer. Or will it answer at all. Because of this algorithm of the fax receiver is something like: Do the "regular" aka "audio" fax reception (inband) At the same time try negotiating T38 with remote side. If (and only if) remote side agrees on T38, stop audio transmittion and switch to T38. Otherwise continue in the audio mode. Also, I do not use setoption at the moment. Only queryoption is used - to get current state of T38 on the channel. This is because fax application does not know in what environment it starts - probably T38 was already negotiated before starting app_fax. After fetching initial status, app_fax does NOT do queryoption repeatedly - insted it gets T38 statys updates from CONTROL frames.
        Hide
        Dmitry Andrianov added a comment -

        typo fixed, thanks to Cache for reporting

        Show
        Dmitry Andrianov added a comment - typo fixed, thanks to Cache for reporting
        Hide
        Dmitry Andrianov added a comment -

        another update - return success from sip_queryoption. This does not affect ANYTHING - it is just about good code style

        Show
        Dmitry Andrianov added a comment - another update - return success from sip_queryoption. This does not affect ANYTHING - it is just about good code style
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 103799

        U trunk/channels/chan_sip.c
        U trunk/include/asterisk/channel.h
        U trunk/include/asterisk/frame.h
        U trunk/main/channel.c
        U trunk/main/frame.c

        ------------------------------------------------------------------------
        r103799 | file | 2008-02-18 17:43:37 -0600 (Mon, 18 Feb 2008) | 6 lines

        Add a non-invasive API for application level manipulation of T38 on a channel. This uses control frames (so they can even pass across IAX2) to negotiate T38 and provided a way of getting the current status of T38 using queryoption. This should by no means cause any issues and if it does I will take responsibility for it.
        (closes issue ASTERISK-11332)
        Reported by: dimas
        Patches:
        v4-t38-api.patch uploaded by dimas (license 88)

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

        http://svn.digium.com/view/asterisk?view=rev&revision=103799

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 103799 U trunk/channels/chan_sip.c U trunk/include/asterisk/channel.h U trunk/include/asterisk/frame.h U trunk/main/channel.c U trunk/main/frame.c ------------------------------------------------------------------------ r103799 | file | 2008-02-18 17:43:37 -0600 (Mon, 18 Feb 2008) | 6 lines Add a non-invasive API for application level manipulation of T38 on a channel. This uses control frames (so they can even pass across IAX2) to negotiate T38 and provided a way of getting the current status of T38 using queryoption. This should by no means cause any issues and if it does I will take responsibility for it. (closes issue ASTERISK-11332 ) Reported by: dimas Patches: v4-t38-api.patch uploaded by dimas (license 88) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=103799

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development