Summary:ASTERISK-11332: [patch] minimal API to control SIP T38 from application
Reporter:Dmitry Andrianov (dimas)Labels:
Date Opened:2008-01-29 18:21:04.000-0600Date Closed:2008-02-18 17:43:47.000-0600
Versions:Frequency of
Environment:Attachments:( 0) v1-t38-api.patch
( 1) v2-t38-api.patch
( 2) v3-t38-api.patch
( 3) v4-t38-api.patch
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.


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
Comments:By: Joshua C. Colp (jcolp) 2008-02-05 11:07:22.000-0600

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.

By: Dmitry Andrianov (dimas) 2008-02-05 14:03:17.000-0600

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.

By: Dmitry Andrianov (dimas) 2008-02-09 04:14:59.000-0600

typo fixed, thanks to Cache for reporting

By: Dmitry Andrianov (dimas) 2008-02-09 05:59:21.000-0600

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

By: Digium Subversion (svnbot) 2008-02-18 17:43:41.000-0600

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
     v4-t38-api.patch uploaded by dimas (license 88)