[asterisk-users] res_fax T.38 Gateway with SpanDSP - Force ReINVITE?

[Larry Moore]

On 25/10/2014 11:43 PM, Larry Moore wrote:
>
>
> On 24/10/2014 12:47 AM, Tim Nelson wrote:
>> ----- Original Message -----
>>>
>>>
>>> On 22/10/2014 11:23 AM, Tim Nelson wrote:
>>>> Greetings-
>>>>
>>>> Working with the T.38 gateway functionality that is sparsely
>>>> documented
>>>> [1], I'm attempting to get the following functional:
>>>>
>>>
>>> What type of endpoint are you using which is originating the call and
>>> is
>>> it T.38 capable?
>>>
>>
>> The originating endpoint is an IAXmodem controlled by Hylafax. Actual
>> call flow is IAXmodem --G.711u via localhost--> Asterisk (old version
>> with no T.38 support) --G.711u--> Asterisk 11.x --G.711u/T.38--> ITSP
>>
>> The problem lies on the Asterisk 11.x system not being able to
>> reinvite to T.38 on the call leg with the ITSP, and given the ITSP
>> does not do this either, the call is stuck in G.711u with varying
>> performance. :/
>>
>> --Tim
>>
>
>
> IAXmodem (other host on network) -> Asterisk 1.2 (IAX) -> Asterisk 1.8
> with Fax Gateway Patch -> SIP provider -> PSTN Fax destination
>
> I have successfully sent a fax using a full page image via an Asterisk
> 1.2 system which forwards the request to my Asterisk 1.8 over an IAX
> channel, Asterisk 1.8 has the T.38 Fax Gateway patch installed. The
> outbound call triggered the T.38 gateway and the fax was received
> without error. I have ECM disabled in my IAX modem configuration in
> Hylafax.
>
> I don't have Asterisk 11 running to test with at this time however I
> confirmed the T.38 Gateway functions in Asterisk 11 when testing it.
>
>
> -- Accepting AUTHENTICATED call from 192.168.54.18:
>  > requested format = ulaw,
>  > requested prefs = (ulaw|alaw|slin),
>  > actual format = alaw,
>  > host prefs = (alaw|ulaw),
>  > priority = mine
> -- Executing [<PSTN Number>@FAX-T30:1] Dial("IAX2/faxgw-iax-1210",
> "SIP/<PSTN Number>@itsp-fax,55") in new stack
> == Using SIP RTP TOS bits 184
> -- Called SIP/<PSTN Number>@itsp-fax
> -- SIP/itsp-fax-0000000b is making progress passing it to
> IAX2/faxgw-iax-1210
> -- SIP/itsp-fax-0000000b is making progress passing it to
> IAX2/faxgw-iax-1210
> == Using SIP RTP TOS bits 184
> -- SIP/itsp-fax-0000000b answered IAX2/faxgw-iax-1210
> [Oct 25 23:24:11] NOTICE[27896]: channel.c:4220 __ast_read: Dropping
> incompatible voice frame on IAX2/faxgw-iax-1210 of format slin since our
> native format has changed to 0x8 (alaw)
> -- Got Fax Tone CED Chan SIP/itsp-fax-0000000b [1] Sending T.38 Params
> Peer Is IAX2/faxgw-iax-1210 [0]
> -- Request on IAX2/faxgw-iax-1210 [0] Storing I: SIP/itsp-fax-0000000b [1]
> == Using UDPTL TOS bits 184
> -- Negotiated on SIP/itsp-fax-0000000b [4] Ignoring I:
> IAX2/faxgw-iax-1210 [0]
> -- T.38 Gateway starting for chan SIP/itsp-fax-0000000b and peer
> IAX2/faxgw-iax-1210
>
> pbx*CLI> iax2 show channels
> Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format
> FirstMsg LastMsg
> IAX2/faxgw-iax-1210 192.168.54.18 faxgw-iax 01210/00004 00010/00005
> 00000ms -0001ms 0000ms alaw Rx:NEW Tx:ACK
> 1 active IAX channel
> pbx*CLI> fax show sessions
>
> Current FAX Sessions:
>
> Channel Tech FAXID Type Operation State File(s)
> SIP/itsp-fax-0000000 Spandsp 1 T.38 receive Active (null)
>
> 1 FAX sessions
>
> -- Executing [h at FAX-T30:1] GotoIf("IAX2/faxgw-iax-1210", "0?2:3") in new
> stack
> -- Goto (FAX-T30,h,3)
> -- Executing [h at FAX-T30:3] NoOp("IAX2/faxgw-iax-1210", "Finish
> if_FAX-T30_37") in new stack
> -- Executing [h at FAX-T30:4] NoOp("IAX2/faxgw-iax-1210", "Call/Fax Ended
> 2014-10-25 23:27:38 +0800") in new stack
> -- Connection Statistics
> Bit Rate :14400
> ECM : No
> Pages : 1
> == Spawn extension (FAX-T30, <PSTN Number>, 1) exited non-zero on
> 'IAX2/faxgw-iax-1210'
> -- Hungup 'IAX2/faxgw-iax-1210'
>

Well, forgive me as I should have had an Asterisk 11 system up and 
running and performing tests before posting.

It would appear there is a behavioural difference with the patch created 
for Asterisk 1.8 and the implementation applied to Asterisk 11.

The observations as listed above relating to the fax gateway stepping 
in, occurs when an outbound fax call is made using either of the g711 
codecs, Asterisk detects the fax tones in the calling leg about 3 
seconds after the call has been answered and sends a T.38 re-invite to 
the ITSP.

Using Asterisk 11, when an outbound call is made, the fax gateway 
detection feature does not do anything on the leg of the call (as you 
have observed) to the ITSP until it receives a T.38 re-invite from the 
ITSP, my observations show this occurs about 4 seconds after the call is 
answered. I suspect once the T.38 re-invite is received from the ITSP, 
the T.38 Gateway sends a T.38 re-invite on the leg of the caller to 
check if it is capable of T.38. I have not confirmed this definitively.

I'm obviously fortunate my ITSP is correctly handling T.38.

Larry.