t.38 Call Flow Information
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
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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@coppice.org> To: freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@coppice.org>* To: *freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
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@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@coppice.org> To: freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@coppice.org>* To: *freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
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@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@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@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@coppice.org> To: freeswitch-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@5ninesolutions.com <mailto:spencer@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@5ninesolutions.com <mailto:spencer@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@coppice.org <mailto:steveu@coppice.org>>* To: *freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@freeswitch.org <mailto:consulting@freeswitch.org> > http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com <http://www.cudatel.com/> > > 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@lists.freeswitch.org <mailto:FreeSWITCH-users@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/> >
participants (3)
-
Anthony Minessale
-
Spencer Thomason
-
Steve Underwood