[Freeswitch-users] t.38 Call Flow Information

Sat Dec 22 08:25:08 MSK 2012

Hi,

If a T.38 gateway or terminal is not prepared to handle ECM, it needs to 
edit the DIS messages to say ECM is not allowed. A problem occurs if you 
have late negotiation of T.38, because the T.38 message modifier is not 
in the path when it is needed, and doesn't edit the messages.

Steve

On 12/22/2012 09:12 AM, Spencer Thomason wrote:
> Hi Anthony,
> I got successful transmission working.
> I'm testing like this:
> Fax Machine --> Linksys SPA-3102 --t.38-- > FS1 --audio --> FS2 (rxfax)
> In analyzing the logs its seems FS2 was reporting the ECM was 
> negotiated where the t38 side from was negotiating ECM off because the 
> Linksys adapter doesn't do ECM.  By explicitly disabling ECM on the 
> receiving end (FS2) everything is working.  Should it not negotiate 
> ECM off all the way through?
>
> Also, I'm still seeing late re-invites so I tried to do:
> <action application="set" data="execute_on_answer=t38_gateway self 
> nocng"/>
>
> That fails with:
> 2012-12-21 17:00:19.617866 [WARNING] mod_spandsp_fax.c:1578 
> sofia/default/1002 at 10.59.1.195 Cannot locate channel with uuid 
> f4b7afd8-4bd2-11e2-b9db-2fac9796034a
>
> I took a look at mod_spandsp.c and can find any reason why that 
> wouldn't work.  Am I missing something or should I file a jira?  The 
> strange thing is that I use nocng with sip_execute_on_image and it 
> works fine.
>
>
> On Dec 21, 2012, at 2:34 PM, Anthony Minessale wrote:
>
>> if you dont need actual detection you can skip it with nocng and jump 
>> right into the processing,
>> You'll have to eyeball it but it should detect it right away, take 
>> note of it by watching the logs.
>>
>>
>>
>> On Fri, Dec 21, 2012 at 4:22 PM, Spencer Thomason 
>> <spencer at 5ninesolutions.com <mailto:spencer at 5ninesolutions.com>> wrote:
>>
>>     I tried tweaking this and it didn't seem to have any effect.  I'm
>>     calling t38_gateway like this:
>>     <action application="set" data="execute_on_answer=t38_gateway self"/>
>>     before the bridge.
>>
>>     Is there anything I should be doing to speed up the detection?  I
>>     should note that is on the receiving end.
>>
>>     The re-invite from rxfax worked without a hitch.  Would this
>>     suggest the default req_counter value is ok?
>>
>>
>>     On Dec 21, 2012, at 9:12 AM, Anthony Minessale wrote:
>>
>>>     you can tweak mod_spandsp_fax.c:1391
>>>
>>>     req_counter is how many packets to wait before sending re-invite.
>>>
>>>     You can play with reducing this number and if its effective it
>>>     could be made into a configurable param.
>>>
>>>
>>>
>>>     On Fri, Dec 21, 2012 at 10:42 AM, Spencer Thomason
>>>     <spencer at 5ninesolutions.com <mailto:spencer at 5ninesolutions.com>>
>>>     wrote:
>>>
>>>         Hi Steve,
>>>         That was my take as well.   I've posted packet captures and
>>>         logs here:
>>>         http://jira.freeswitch.org/browse/FS-4957
>>>
>>>         Is there any way to speed up the ReINVITE?
>>>
>>>         Thanks,
>>>         Spencer
>>>
>>>
>>>         -----Original message-----
>>>
>>>             *From: *Steve Underwood <steveu at coppice.org
>>>             <mailto:steveu at coppice.org>>*
>>>             To: *freeswitch-users at lists.freeswitch.org
>>>             <mailto:freeswitch-users at lists.freeswitch.org>*
>>>             Sent: *Fri, Dec 21, 2012 09:57:07 GMT+00:00*
>>>             Subject: *Re: [Freeswitch-users] t.38 Call Flow Information
>>>
>>>             Hi,
>>>
>>>             It looks like your reinvite occurred extremely late, and
>>>             the FAX was
>>>             already deep in progress as an audio exchange.
>>>
>>>             Steve
>>>
>>>
>>>             On 12/21/2012 03:14 AM, Spencer Thomason wrote:
>>>             > Hello,
>>>             > I've been analyzing some Wireshark traces to get a
>>>             better grasp on the t.38 gateway process. I'm using
>>>             t38_gateway to convert SIP t38 to TDM audio on the
>>>             receiving end. I'm struggling to understand the
>>>             following call flow. I've excluded the audio portion for
>>>             brevity but t38 is negotiated correctly by both
>>>             endpoints (FS on our end and Acme on the other). Note
>>>             the absence of a DIS message and the PPS prior to CFR.
>>>             Can anyone shed any light on this?
>>>             >
>>>             > Thanks in advance,
>>>             > Spencer
>>>             >
>>>             >
>>>             > Acme FreeSWITCH
>>>             > |1716.691635| INVITE SDP (t38) | |SIP Request
>>>             > | |(5060) <------------------ (5070) | |
>>>             > |1716.719556| 100 trying -- your call is important to
>>>             us | |SIP Status
>>>             > | |(5060) ------------------> (5070) | |
>>>             > |1716.830431| | no-signal | |t38:t30 Ind:no-signal
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1716.906132| 200 OK SDP (t38) | |SIP Status
>>>             > | |(5060) ------------------> (5070) | |
>>>             > |1716.912839| ACK | | |SIP Request
>>>             > | |(5060) <------------------ (5070) | |
>>>             > |1716.973011| | no-signal | |t38:t30 Ind:no-signal
>>>             > | | |(21440) ------------------> (15876) |
>>>             > |1717.450595| | v21-preamble |t38:t30 Ind:v21-preamble
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1717.730869| | PPS | |t38:v21:HDLC:Partial Page Signal
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1717.780811| | no-signal | |t38:t30 Ind:no-signal
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1718.130798| | v17-14400-long-training |t38:t30
>>>             Ind:v17-14400-long-training
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1719.541095| | t4-non-ecm-data:v17-14400
>>>             |t38:t4-non-ecm-data:v17-14400 Duration: 1.51s No packet
>>>             lost
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1721.060850| | no-signal | |t38:t30 Ind:no-signal
>>>             > | | |(21440) <------------------ (15876) |
>>>             > |1722.573572| | v21-preamble |t38:t30 Ind:v21-preamble
>>>             > | | |(21440) ------------------> (15876) |
>>>             > |1723.593652| | CFR | |t38:v21:HDLC:Confirmation To
>>>             Receive
>>>             >
>>>             _________________________________________________________________________
>>>             > Professional FreeSWITCH Consulting Services:
>>>             > consulting at freeswitch.org
>>>             <mailto:consulting at freeswitch.org>
>>>             > http://www.freeswitchsolutions.com
>>>             <http://www.freeswitchsolutions.com/>
>>>             >
>>>             > FreeSWITCH-powered IP PBX: The CudaTel Communication
>>>             Server
>>>             >  </>
>>>             >
>>>             > Official FreeSWITCH Sites
>>>             > http://www.freeswitch.org <http://www.freeswitch.org/>
>>>             > http://wiki.freeswitch.org <http://wiki.freeswitch.org/>
>>>             > http://www.cluecon.com <http://www.cluecon.com/>
>>>             >
>>>             > FreeSWITCH-users mailing list
>>>             > FreeSWITCH-users at lists.freeswitch.org
>>>             <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>>             >
>>>             http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>             >
>>>             UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>             > http://www.freeswitch.org <http://www.freeswitch.org/>
>>>             >
>>>