[Home]

Summary:ASTERISK-13915: [patch] SendFax function not working as expected on > 1.6.0.7
Reporter:Andres Felipe Osorio (afosorio)Labels:
Date Opened:2009-04-07 15:51:43Date Closed:2009-07-20 12:46:20
Priority:BlockerRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_fax_t38_send_receive.patch
( 1) v1-14849.patch
( 2) v2-14849.patch
Description:When trying to send a fax via callfile using T.38 in asterisk version 1.6.0.5 it works fine, but after upgrading to asterisk 1.6.0.7 or newer it does not work. When receiving re-INVITE from media gateway (Cisco AS-5400) Asterisk ends call answering 488 Not acceptable here. I am running Asterisk under Debian kernel 2.6.18-6-686. I am attaching captures both for scenario which works and scenario which does not work.

****** ADDITIONAL INFORMATION ******

Using Asterisk 1.6.0.5

U 192.168.30.1:5060 -> 192.168.30.2:5060
INVITE sip:4133333@192.168.30.2 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK756c0c01;rport.
Max-Forwards: 70.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
To: <sip:4133333@192.168.30.2>.
Contact: <sip:3950026@192.168.30.1>.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 102 INVITE.
User-Agent: mu1.
Date: Tue, 07 Apr 2009 20:05:25 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 291.
.
v=0.
o=root 1535376181 1535376181 IN IP4 192.168.30.1.
s=Asterisk PBX 1.6.0.5.
c=IN IP4 192.168.30.1.
t=0 0.
m=audio 10096 RTP/AVP 8 0 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK756c0c01;rport=5060.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
To: <sip:4133333@192.168.30.2>.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 102 INVITE.
Content-Length: 0.

U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK756c0c01;rport=5060.
To: <sip:4133333@192.168.30.2>;tag=35c155bd.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq:  102 INVITE.
Record-Route: <sip:192.168.30.2;lr;ftag=as74e6d875;did=7a4.f09>.
Supported:  replaces, timer.
Accept: application/sdp, application/isup, application/xml.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Max-Forwards:  69.
Contact: <sip:4133333.iIiIiI.0a010705.@200.13.234.200>.
Content-Type: application/sdp.
Content-Length: 260.
.
v=0.
o=- 0 8365233 IN IP4 10.1.7.5.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=audio 18926 RTP/AVP 0 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.

U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK756c0c01;rport=5060.
To: <sip:4133333@192.168.30.2>;tag=35c155bd.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq:  102 INVITE.
Record-Route: <sip:192.168.30.2;lr;ftag=as74e6d875;did=7a4.f09>.
Supported:  replaces, timer.
Accept: application/sdp, application/isup, application/xml.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Max-Forwards:  69.
Contact: <sip:4133333.iIiIiI.0a010705.@200.13.234.200>.
Content-Type: application/sdp.
Content-Length: 260.
.
v=0.
o=- 0 8365233 IN IP4 10.1.7.5.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=audio 18926 RTP/AVP 0 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.

U 192.168.30.1:5060 -> 192.168.30.2:5060
ACK sip:4133333.iIiIiI.0a010705.@200.13.234.200 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK25af46b1;rport.
Route: <sip:192.168.30.2;lr;ftag=as74e6d875;did=7a4.f09>.
Max-Forwards: 70.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
To: <sip:4133333@192.168.30.2>;tag=35c155bd.
Contact: <sip:3950026@192.168.30.1>.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 102 ACK.
User-Agent: mu1.
Content-Length: 0.

U 192.168.30.2:5060 -> 192.168.30.1:5060
INVITE sip:3950026@192.168.30.1 SIP/2.0.
Record-Route: <sip:192.168.30.2;lr;ftag=35c155bd>.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bK032.82a1.0.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010705.35c16251.
To:  "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
From:<sip:4133333@192.168.30.2>;tag=35c155bd.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq:  103 INVITE.
Max-Forwards: 69.
Contact: <sip:4133333.iIiIiI.0a010705.@200.13.234.200>.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Accept: application/sdp, application/isup, application/xml.
Content-Type: application/sdp.
Content-Length: 204.
.
v=0.
o=- 0 8365263 IN IP4 10.1.7.5.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=image 18926 udptl t38.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.


U 192.168.30.1:5060 -> 192.168.30.2:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bK032.82a1.0;received=192.168.30.2.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010705.35c16251.
Record-Route: <sip:192.168.30.2;lr;ftag=35c155bd>.
From: <sip:4133333@192.168.30.2>;tag=35c155bd.
To: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 103 INVITE.
User-Agent: mu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3950026@192.168.30.1>.
Content-Length: 0.

U 192.168.30.1:5060 -> 192.168.30.2:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bK032.82a1.0;received=192.168.30.2.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010705.35c16251.
Record-Route: <sip:192.168.30.2;lr;ftag=35c155bd>.
From: <sip:4133333@192.168.30.2>;tag=35c155bd.
To: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 103 INVITE.
User-Agent: mu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3950026@192.168.30.1>.
Content-Type: application/sdp.
Content-Length: 376.
.
v=0.
o=root 1535376181 1535376182 IN IP4 192.168.30.1.
s=Asterisk PBX 1.6.0.5.
c=IN IP4 192.168.30.1.
t=0 0.
m=image 4415 udptl t38.
a=T38FaxVersion:0.
a=T38MaxBitRate:9600.
a=T38FaxFillBitRemoval:0.
a=T38FaxTranscodingMMR:0.
a=T38FaxTranscodingJBIG:0.
a=T38FaxRateManagement:transferredTCF.
a=T38FaxMaxBuffer:400.
a=T38FaxMaxDatagram:400.
a=T38FaxUdpEC:t38UDPRedundancy.


U 192.168.30.2:5060 -> 192.168.30.1:5060
ACK sip:3950026@192.168.30.1 SIP/2.0.
Record-Route: <sip:192.168.30.2;lr;ftag=35c155bd>.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bK032.82a1.2.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010705.35c16268.
To:  "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
From:<sip:4133333@192.168.30.2>;tag=35c155bd.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq:  103 ACK.
Max-Forwards: 69.
Content-Length: 0.


U 192.168.30.1:5060 -> 192.168.30.2:5060
BYE sip:4133333.iIiIiI.0a010705.@200.13.234.200 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK704a6e62;rport.
Route: <sip:192.168.30.2;lr;ftag=as74e6d875;did=7a4.f09>.
Max-Forwards: 70.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
To: <sip:4133333@192.168.30.2>;tag=35c155bd.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 103 BYE.
User-Agent: mu1.
Content-Length: 0.
.


U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK704a6e62;rport=5060.
To: <sip:4133333@192.168.30.2>;tag=35c155bd.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as74e6d875.
Call-ID: 60ecebc222983c2810d225de4099a82c@192.168.30.1.
CSeq: 103 BYE.
Record-Route: <sip:192.168.30.2;lr;ftag=35c155bd>.
Accept: application/sdp, application/isup, application/xml.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Max-Forwards: 70.
Contact: <sip:4133333.iIiIiI.0a010705.@200.13.234.200>.
Content-Length: 0.

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

Using Asterisk 1.6.0.7 or newer

U 192.168.30.1:5060 -> 192.168.30.2:5060
INVITE sip:4133333@192.168.30.2 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK002d8b2a;rport.
Max-Forwards: 70.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
To: <sip:4133333@192.168.30.2>.
Contact: <sip:3950026@192.168.30.1>.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq: 102 INVITE.
User-Agent: mu1.
Date: Tue, 07 Apr 2009 16:37:53 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 289.
.
v=0.
o=root 548293083 548293083 IN IP4 192.168.30.1.
s=Asterisk PBX 1.6.0.9.
c=IN IP4 192.168.30.1.
t=0 0.
m=audio 11904 RTP/AVP 8 0 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK002d8b2a;rport=5060.
To: <sip:4133333@192.168.30.2>;tag=ed54fbd8.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq:  102 INVITE.
Record-Route: <sip:192.168.30.2;lr;ftag=as40099790;did=1a5.61e4>.
Supported:  replaces, timer.
Accept: application/sdp, application/isup, application/xml.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Max-Forwards:  69.
Contact: <sip:4133333.iIiIiI.0a010709.@200.13.234.200>.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=- 0 15474723 IN IP4 10.1.7.9.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=audio 18838 RTP/AVP 0 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.

U 192.168.30.2:5060 -> 192.168.30.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK002d8b2a;rport=5060.
To: <sip:4133333@192.168.30.2>;tag=ed54fbd8.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq:  102 INVITE.
Record-Route: <sip:192.168.30.2;lr;ftag=as40099790;did=1a5.61e4>.
Supported:  replaces, timer.
Accept: application/sdp, application/isup, application/xml.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Max-Forwards:  69.
Contact: <sip:4133333.iIiIiI.0a010709.@200.13.234.200>.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=- 0 15474723 IN IP4 10.1.7.9.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=audio 18838 RTP/AVP 0 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.

U 192.168.30.1:5060 -> 192.168.30.2:5060
ACK sip:4133333.iIiIiI.0a010709.@200.13.234.200 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.1:5060;branch=z9hG4bK6288e670;rport.
Route: <sip:192.168.30.2;lr;ftag=as40099790;did=1a5.61e4>.
Max-Forwards: 70.
From: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
To: <sip:4133333@192.168.30.2>;tag=ed54fbd8.
Contact: <sip:3950026@192.168.30.1>.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq: 102 ACK.
User-Agent: mu1.
Content-Length: 0.

U 192.168.30.2:5060 -> 192.168.30.1:5060
INVITE sip:3950026@192.168.30.1 SIP/2.0.
Record-Route: <sip:192.168.30.2;lr;ftag=ed54fbd8>.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bKbf5b.89e6.0.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010709.305033b6.
To:  "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
From:<sip:4133333@192.168.30.2>;tag=ed54fbd8.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq:  103 INVITE.
Max-Forwards: 69.
Contact: <sip:4133333.iIiIiI.0a010709.@200.13.234.200>.
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE.
Accept: application/sdp, application/isup, application/xml.
Content-Type: application/sdp.
Content-Length: 205.
.
v=0.
o=- 0 15474750 IN IP4 10.1.7.9.
s=IMSS.
c=IN IP4 190.248.16.66.
t=0 0.
m=image 18838 udptl t38.
a=X-sqn:0.
a=X-cpar: a=rtpmap:101 X-NSE/8000.
a=X-cpar: a=fmtp:101 200-202.
a=X-cap: 2 image udptl t38.


U 192.168.30.1:5060 -> 192.168.30.2:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bKbf5b.89e6.0;received=192.168.30.2.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010709.305033b6.
Record-Route: <sip:192.168.30.2;lr;ftag=ed54fbd8>.
From: <sip:4133333@192.168.30.2>;tag=ed54fbd8.
To: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq: 103 INVITE.
User-Agent: mu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3950026@192.168.30.1>.
Content-Length: 0.


U 192.168.30.1:5060 -> 192.168.30.2:5060
SIP/2.0 488 Not acceptable here.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bKbf5b.89e6.0;received=192.168.30.2.
Via: SIP/2.0/UDP 200.13.234.200:5060;rport=5060;branch=z9hG4bK.iIiIiI.0a010709.305033b6.
From: <sip:4133333@192.168.30.2>;tag=ed54fbd8.
To: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
CSeq: 103 INVITE.
User-Agent: mu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Content-Length: 0.
X-Asterisk-HangupCause: Normal Clearing.
X-Asterisk-HangupCauseCode: 16.
.

U 192.168.30.2:5060 -> 192.168.30.1:5060
ACK sip:3950026@192.168.30.1 SIP/2.0.
Via: SIP/2.0/UDP 192.168.30.2;branch=z9hG4bKbf5b.89e6.0.
From:<sip:4133333@192.168.30.2>;tag=ed54fbd8.
Call-ID: 1a0f6a575506c9227af65e14072de2e7@192.168.30.1.
To: "3660010" <sip:3950026@192.168.30.1>;tag=as40099790.
CSeq:  103 ACK.
Max-Forwards: 70.
Content-Length: 0.

The log file show:

[Apr  7 11:54:52] ERROR[12953] channel.c: ast_read() called with no recorded file descriptor.
Comments:By: Andrew Lindh (andrew) 2009-04-07 16:03:32

Thanks for posting this, I was just looking into why T.38 did not work for me with outbound calls using asterisk trunk.

Note, the error: "channel.c: ast_read() called with no recorded file descriptor"
Is unrelated to the T.38 problem. See bug id ASTERISK-1456723
To fix that error when using fax (not the T.38 problem) see bug id ASTERISK-1460769


By: Kristijan Vrban (vrban) 2009-04-29 20:00:24

hello, i can confirm the "488 Not acceptable here." issue with Asterisk >1.6.0.5 I test it with a Grandstream HT502 (FW 1.0.1.35)

After chan_sip reply "488 Not acceptable here", the HT502 fall back to send fax with ulaw.

With 1.6.0.5 the T.38 transmission starts, but then fail when the fax machine start to to move in the fax sheet. But this is deeper spandsp/T.38 problem with the grandstream's T.38
By: Gentian Bajraktari (gentian) 2009-04-30 02:41:56

hi Vrban you are right! I am experiencing the same problem. And I tried all possible clients like Linksys SPA2102, Grandstream208, Zhone DSLAM with POTS ports etc

but I allways though it was more a problem of the FaxGateway patch. but if you are experiencing that with SendFax application then it seems more of a general problem. I will try to install 1.6.0.5 and see if it works. Have you tried the new released 1.6.1.0 ?
By: Kristijan Vrban (vrban) 2009-05-01 06:17:40

@all have you tried to SendFax from one asterisk to the ReceiveFAX of an other asterisk? I have done it to encircle this issue, with curious result:

*s = asterisk 1, SendFax
*r = asterisk 2, ReceiveFAX

1. *s send it's INVITE to *r. without T.38 in sdp, what correct, because the receiver *r shall re-invite with T.38

2. *r now send it's re-invite with T.38 to s* (after: app_fax.c:469 transmit_audio: Fax tone detected. Requesting T38) and *s send a "100 Trying" to this T.38 re-invite.

3. Till now all is ok. But now the curious part begin:

Right after the "100 Trying" from *s the SendFax and ReceiveFAX between *s and *r start to transmit the fax with audio T.30 (not T.38!), and before *s send the "488 Not acceptable here", the whole fax is already and _complete_ transferred with T.30!?
 
4. After the fax is transfered, *s and *r send some "503 Unavailable" back and forth, because the SIP transmission is also messed up then.

can someone reproduce this?

@gentian
i tested with 1.6.2-svn, but this behave should be identical with all versions after ast_1.6.0.5
By: Gentian Bajraktari (gentian) 2009-05-01 08:51:59

so we can say that t.38 implemantation is broken starting from 1.6.0.6...
By: Kristijan Vrban (vrban) 2009-05-02 17:42:24

hi, i made a patch for myself that fix this issue by doing a hard coded SipT38SwitchOver in app_fax. whatever we detect a faxtone or not. (because it never detect a fax tone, cant say why) And my opinion is, that if we get a call to the ReceiveFAX application from a SIP channel, i dont see any reason why a SipT38SwitchOver should not be hard coded?

Waiting to detect a fax tone can fail for a variety of reasons, e.g. narrow band codec. While sending a re-invite to offer T.38 is a most normal thing if we get a call to the ReceiveFAX application.

agreement/disagreement ?

Update:
The report here is mainly about SendFax, but it's the same with it. If we send out a fax, and the counterpart offer us T.38, the first thing to do is to say: "Yes, sure, many thanks!" and not "hmm.. wait iam am not sure... really T.38?" wait i first want to look into the audio if the fax i send really is a fax... hmm... well, iam unsure. let's do audio faxing"

A bit ironic, but that exactly describes the current behave in app_fax.c


By: Gentian Bajraktari (gentian) 2009-05-03 03:26:35

hi vrban, can you send me that patch? so that I can test.
By: Dmitry Andrianov (dimas) 2009-05-03 03:40:52

vrban ,
"And my opinion is, that if we get a call to the ReceiveFAX application from a SIP channel, i dont see any reason why a SipT38SwitchOver should not be hard coded?"
Before stating this you read T38 specifications of course? Because last time I read it, it was saying that receiving end should initiate switchover when it hears CNG...

Also, last time I tried, Callweaver on sending  side was terminmating the call if Asterisk on receiving side did T38 reinvite right at the beginning of ReceiveFAX.

And your comment about SendFax is meaningless - again, it is up to RECEIVING end to offer switchover not sending one. Send fax does not "look into audio" at all. If you check the code you will find that CNG detection is done only for receive mode (that is ReceiveFAX). If Asterisk is the sender - it will do switchover as soon as it gets proper INVITE. (At least it was doing that when I was trying half an year ago)


By: Gentian Bajraktari (gentian) 2009-05-04 14:54:59

hi it seems more of a codec problem.
When asterisk receives invite for T.38 it complains that there is no audio codec in the path so it just hangup the call with 488 unacceptable due to codec mismatch. so asterisk thinks that the T.38 reinvite is just another call but since the Sipura or any other ATA send the invite only with T.38 codec with no audio codec asterisk does not accept that...
By: Volnikov Ivan (ivan) 2009-05-30 02:35:37

hi! I looking for bug in t38 switching procedure when ReceiveFax process(1.6.1.0 release). It occurs when remote peer switchs media in t38 in the case of V.21 Preamble has detected or if softphone itself switch in t38 without CNG. Seems like it is the same problem.
By: Volnikov Ivan (ivan) 2009-05-30 02:53:07

I am put a patch (app_fax_t38_send_receive.patch for 1.6.1.0 release) that solve this problem and possible in other cases when in t38 switch occurs at the initiative of the remote party.
Success tests (SendFax and ReceiveFax) were carried out on:
1) AudioCodes GW MP-112
2) AudioCodes GW Mediant 1000 ML
3) LinkSys GW SPA3102
4) ZoIPer SoftPhone
5) Interlink GW RNG-120
By: Andrew Lindh (andrew) 2009-05-30 04:02:49

With the patch I get an error at the end of the fax, but it works. It might just be the end of call hangup being reported as an error. I'm using a Cisco AS5300 gateway and PRI (send and receive).

If T38 is not enabled correctly in sip.conf, but supported I will get the following error: "Audio loop reports T38 switchover but t38state != T38_STATE_NEGOTIATED". It should use the audio codec rather than fail.
By: Gentian Bajraktari (gentian) 2009-05-30 05:42:49

Does this work on 1.6.0.9 ?
By: Dmitry Andrianov (dimas) 2009-05-30 05:48:56

Ivan,
I believe your patch is not very correct: you can only suggest chan_sip to initiate or accept T38 (both of which is done with AST_T38_REQUEST_NEGOTIATE) and should wait for the confirmatiion from the chan_sip (which is AST_T38_NEGOTIATED).

If you look at the code, you will find that actually chan_sip handles AST_T38_REQUEST_NEGOTIATE and AST_T38_NEGOTIATED control frames exactly the same way - this is why your patch works too. However I believe, the correct approach is described above.

I'm attaching patch however I did not test it.

Andrew, could you please test the patch?


By: Volnikov Ivan (ivan) 2009-05-30 11:16:23

Dimas,
What APPLICATION do need wait if Re-Invite for t38 was received? ACK? It is not work for APPLICATION! We must confirm negotiation. It ALL!
By: Volnikov Ivan (ivan) 2009-05-30 11:29:06

Applicaton Must wait only if was sending Re-Invite request before it is received
By: Volnikov Ivan (ivan) 2009-05-31 00:15:09

andrew, try insert Wait(2) in dialplan after SendFax or show me dcpdump for fax session in Asterisk. In my tests all end of fax are completed correctly


By: Dmitry Andrianov (dimas) 2009-05-31 16:28:45

Ivan,
the idea is that application does not know internals of the channel driver. For SIP, yes, when re-invite is received you may be sure that accepting it will result in established T38 session. But that is SIP specific and application should not rely on these specific things. If T38 will ever be supported on any other protocol in addition to SIP in the future, you may not know in advance how that protocol would work. It is possible that even when you accept incoming T38 offer, the protocol still requires few extra packet exchanges before the T38 negotiation is complete. Because of that, you should not rely on the fact that as soon as you respond to T39 offer it means T38 is on. Instead you should just tell channel driver "yes, I agree" and wait when channel driver confirms transition. For SIP this wait may be redundant, but that is how robust software is written...


By: Volnikov Ivan (ivan) 2009-06-01 01:00:56

Dimas,
I very much would not like to argue especially with the author of a code. I have expressed the opinion grounded on a wide experience of a spelling of a code for various signalling systems (PSTN or VoIP). Let us will be judged by others. I think it must be people who are responsible for the architecture of a "channel outcome". If for you is what to discuss privately - welcome in ICQ. We can easy work out a consensus in this respect.
By: Andrew Lindh (andrew) 2009-06-01 08:48:47

Both patches work for me, but have the same problem which may be an issue elsewhere in the code. If T38 is enabled for the Peer but not in Global T38 is selected but fails. I guess this is not a big deal.

Adding the wait before calling FAX (I tried 1-4 seconds) did not help with T38, the added wait even made some faxes fail with audio mode.
By: Volnikov Ivan (ivan) 2009-06-01 09:14:36

andrew, If the problem ("error at the end of the fax") is still present, please insert Wait(2) AFTER calling SendFax Application or better attach me tcpdump file while t38 session closing (may be there is a trouble coming back while switching in audio mode from t38). Are you work with 1.6.1.0 version?


By: Dmitry Andrianov (dimas) 2009-06-01 09:24:28

andrew,
in my setups I also had to enable udptl globally in order for the thing to work. However I believe it is not a bug in fax application but rather a bug in chan_sip.
By: Andrew Lindh (andrew) 2009-06-08 11:41:44

I don't see that small problem as a real bug. I think the error after the fax is just not detecting the hangup correctly in the app.
By: Dmitry Andrianov (dimas) 2009-06-08 12:28:00

lmadsen,
I believe there is no reason to postpone this paatch for later version - it can be safely committed. At least it does not break anything...
By: Volnikov Ivan (ivan) 2009-06-11 08:16:43

andrew,
I do found problem with sending fax in t.38 mode at end of phase while sip channel switching in voice mode by remote side. app_fax abnormally terminating at the end of t.38 transmit. That leads to soft-handup channel and abort dialplan. I have not acceptible desigion while. Seems like it is chan_sip problem
By: Andrew Lindh (andrew) 2009-06-11 10:02:52

In my dialplan setup I use the h (hangup) extension as the end of the fax call (hard or soft hangup) and then do post processing. You can NOT count on the call continuing after the end of the fax.
By: Mark Michelson (mmichelson) 2009-06-15 16:33:14

dimas: lmadsen asked me to take a look and get this patch committed. Faxing is not exactly my area of expertise, though, so I don't really understand the change here. Could you sum up the change so that I can explain it in  my commit message? Thanks!
By: Dmitry Andrianov (dimas) 2009-06-15 17:36:16

Sure.
chan_sip used to instantly accept T38 reinvite offer when offered by remote peer. After accepting the offer, chan_sip sends AST_T38_NEGOTIATED. app_fax receives the frame and knows that switchover is done, terminates audio loop and switches to T38 mode.

In the commit 183108 ( see http://reviewboard.digium.com/r/200/ ) file changed the logic of chan_sip to not blindly accept T38 reinvite but send AST_T38_REQUEST_NEGOTIATE request frame into asterisk core. So if someone (like application) is interested in the T38, it will agree to switch (by indicating AST_T38_REQUEST_NEGOTIATE back) and then chan_sip will finally do the switchover (again, producing AST_T38_NEGOTIATED at the end). If noone on the application side agrees to T38 in 5 seconds, chan_sip will refuse the offer with 488 Not Acceptable Here.

The only problem is that app_fix was not updated to account that change so it keeps waiting for AST_T38_NEGOTIATED which will never come until the application itself confirms AST_T38_REQUEST_NEGOTIATE coming from the channel driver.
By: Volnikov Ivan (ivan) 2009-06-15 23:51:27

Moreover,
In the end of T.38 fax session chan_sip send to application AST_T38_TERMINATED when shitch back to RTP by remote point ended after success in t.38 session. BUT application app_fax is not inform about IT (process in spandsp did not complete)!!! Why switch to T.38 MUST be confirmed in application but back to RTP DO NOT? It is a BUG in chan_sip! And that bug bring to world in the same "commit 183108" (I think) where logic of this procedure was changed! In the case of "SendFax" sending fax do not complete successfully. It is not small problem as say andrew. I realy can not use channel further in dialplan after "SendFax".
By: Volnikov Ivan (ivan) 2009-06-15 23:57:54

dimas: if there will be time answer for my question in ICQ. There is one more problem in this (???) issue
By: Dmitry Andrianov (dimas) 2009-06-16 02:22:47

Ivan, I'm I have very limited access to my ICQ for the next 3 weeks so it is not the best way to communicate. Please use email instead.

Ivan and andrew, please try the simple fix - in the transmit_t38 loop after the
ast_debug(1, "T38 down, terminating\n");
set res to 0 instead of -1 and see if it fixes anything. Lets leave it upto the spandsp to decidde if there were error or not and do not force error conddition ourselves...

Ivan, in ANY case you should NOT rely on dialplan to continue after the SendFax/ReceiveFax - all post-processing (emailing, saving status to DB etc) should be done in 'h' extension handler.
By: Volnikov Ivan (ivan) 2009-06-16 02:44:32

Dimas,
I comment (a week ago) reaction on AST_T38_TERMINATED in condition and problem is disappear. Like that:
ast_debug(1, "T38 control event receve <%d>\n",t38control);

if (/*t38control == AST_T38_TERMINATED ||*/ t38control == AST_T38_REFUSED) {
ast_debug(1, "T38 down, terminating\n");
res = -1;
break;
}

Fix needs in chan_sip. In new file ideology AST_T38_TERMINATED is not ERROR. But where is AST_T38_REQUEST_TERMINATE?
By: Dmitry Andrianov (dimas) 2009-06-16 03:02:44

Yest, T38 termination is not an error. And that is what I'm trying to say with changing

res = -1 to res = 0;
Andrew, could you please check if it works for you?
By: Volnikov Ivan (ivan) 2009-06-16 06:02:07

dimas, make "break" :) in that case - not good decision. The "spandsp" cycle is not completed while and not all data can be produced.
By: Dmitry Andrianov (dimas) 2009-06-16 06:06:02

There will be no more data to spandsp anyway - the T38 session just terminated...
By: Andrew Lindh (andrew) 2009-06-16 06:14:20

I'll take a look. I guess the original idea is the system could switch back to audio so you could talk before and after a fax, like two people might do back in the 1970's.... but since this is a computer the end of the fax should just be the end of the call.
By: Dmitry Andrianov (dimas) 2009-06-16 06:18:29

andrew, at the moment app_fax was created, there just were NO support in the chan_sip for switching back to voice. I do not think there is any now.

Also, changing res=-1 to res=0 in that place does not change logic there at all. The only change will be that app_fax will _attempt_ to finish successfully instead of guaranteed error.
By: Volnikov Ivan (ivan) 2009-06-16 06:20:39

Very much even can be. And they are. SIP Signalling and UDPTL stream on real networks remarkably have racing.
By: Volnikov Ivan (ivan) 2009-06-16 06:30:30

andrew, back to audio is Regular procedure of work with t38. For my application is a necessary thing. What for I should lose the client if it is simple through system have taken away a fax?
By: Dmitry Andrianov (dimas) 2009-06-16 06:30:57

Give me just an idea why remote end offers switching back to voice when it still transmitting UDPTL ?
By: Volnikov Ivan (ivan) 2009-06-16 06:50:30

Dima, two:
1. SIP UDP packet has overtaken packet UDPTL(same UDP) in a network and has got to queue of the channel earlier - the real way for packets may be different
2. The QUEUE of events on SIP transport will be processed faster than UDPTL and will fall in QUEUE of the channel earlier

I really observed such situations and not only on the Asterisk


By: Dmitry Andrianov (dimas) 2009-06-16 07:17:34

Well, surely we are talking about a few UDPTL packets which are in-transit/in the queue. It should not make any difference if you receive them or not. Properly designed equipment definitely won't be sending any meaningful/important UDPTL packets if it already offered the other end to finish with UDPTL at all.

After all, if you are not breaking the loop when T38 is down, you may create even more dangerous situation - if spandsp does not think the transmission is over yet but no more UDPTLs are coming, the packet processing loop will just hang for a long time.
By: Volnikov Ivan (ivan) 2009-06-16 09:19:40

dimas, :( I do not understand you. What ratio "Properly designed equipment" has to the various path for UDPTL and SIP[:5060]? There is no way correctly to SYNC it without reception in application event AST_T38_REQUEST_TERMINATE from chan_sip and while t.38 session correctly do not closed not confirm it.

My and your solution - only stubs. It is necessary to correct chan_sip. I will try to find time to days off to be engaged. I have there other problem which should be discussed in Russian


By: Dmitry Andrianov (dimas) 2009-06-16 10:55:03

Ivan,
do you state that res=0 fix does not work (and you tested) or you just think it will not work?
By: Mark Michelson (mmichelson) 2009-06-16 14:28:17

Hmm, it seems that there may still be more work to make sure this issue is actually resolved. I'll wait until dimas and Ivan have reached a consensus.
By: Volnikov Ivan (ivan) 2009-06-17 00:37:45

Dimas,
Comment /*t38control == AST_T38_TERMINATED ||*/ it realy work! I will try your method today.
By: Volnikov Ivan (ivan) 2009-06-17 02:03:37

Diams, It works the same as /*t38control == AST_T38_TERMINATED ||*/
But the same :( as in my next fax I can not Send (or Receive) in the same channel session. There is no data from channel in app_fax. I will understand now with it. I think it is Other Issue.
Are we study on a subject "chan_sip with AST_T38_REQUEST_TERMINATE"?
By: Dmitry Andrianov (dimas) 2009-06-17 02:20:54

Ivan, thanks for testing.
Andrew, please try new patch v2-14849.patch - it combines both fixes.

Well, I think if app_fax receives fax ok and exits to dialplan normally, then it works :) If it is unable to send multiple faxes in the same session, it definitely should be investigated but I would suggest filling another issue for it. Otherwise we will stick with this ussue forever trying to fix newly discovered problems with the fax which are often unrelated to each other.
By: Volnikov Ivan (ivan) 2009-06-17 07:10:10

No basic claims I have at while time. Finally dimas is the author of app_fax. Therefore to him and to make solution. In my system I stay in myself changes while.
By: Leif Madsen (lmadsen) 2009-06-24 13:10:32

Changed target to 1.6.0.12 hoping someone will get to this before then.
By: Dmitry Andrianov (dimas) 2009-06-24 13:16:44

lmaidsen, mmichelson,
I believe we should proceed with committing the patch because at least if fixes the "T38 fax termination completely non-working" issue.

The changes in chan_sip Ivan proposing can take unpredictable time from him to implement. And these changes will add nioe-to-have feature not fix the bug explained here.
By: Andrew Lindh (andrew) 2009-06-24 13:57:48

I sent a few faxes with the v2-14849 patch and T38 seems to work fine for me. I get an error sometimes, but it's because of other T38 issues between Cisco and the SPANDSP software (not an asterisk problem). My test setup is still asterisk trunk and cisco AS5300 with a PRI. I'm only sending one fax per call/session. I'm not trying any advanced features, just send a fax/receive a fax.

Let's fix an useful feature with a simple patch so more people can use it.


By: Mike Oliveras (moliveras) 2009-06-24 15:19:27

I would also like to see this patch committed - without it t38 fax is completely broken for me.  The patch fixed my issue.. Can a separate bug be created to track what is left?  I see no point in leaving it broken.
By: Leif Madsen (lmadsen) 2009-06-29 11:11:24

Marking this Ready for Review. If there is additional work to be done here, then it needs to be tracked in a separate issue. Please open that issue when the patch has been created.

This will go in once a developer has reviewed and approved it. Thanks!
By: Volnikov Ivan (ivan) 2009-06-29 11:58:03

lmadsen, It is the correct decision for this Issue. I make separate Issue when it will be possible to formalize and fix two problems:
- non-reqested for application switch t38->audio
- fail second (and other) fax session for call
By: Andres Felipe Osorio (afosorio) 2009-07-08 14:54:39

I test the patch v2-14849.patch in asterisk 1.6.0.11-rc1 and the application SendFAX work fine. Thanks Dimas and Ivan for all your help.
By: Andrew Lindh (andrew) 2009-07-08 15:55:37

The current trunk breaks a lot of stuff...
By: Gentian Bajraktari (gentian) 2009-07-09 04:13:59

will this patch and the t.38 gateway patch (13405) happily work togather on asterisk-trunk?
By: Dmitry Andrianov (dimas) 2009-07-09 05:17:21

have no idea. In theory these patches are unrelated and gateway is separate application so it should not affect SendFAX/ReceiveFAX. However I never tested it.
By: Digium Subversion (svnbot) 2009-07-09 16:20:24

Repository: asterisk
Revision: 205696

U   trunk/apps/app_fax.c
U   trunk/channels/chan_sip.c
U   trunk/include/asterisk/frame.h

------------------------------------------------------------------------
r205696 | kpfleming | 2009-07-09 16:20:24 -0500 (Thu, 09 Jul 2009) | 16 lines

Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.

Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).

This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.

(closes issue ASTERISK-13915)
Reported by: afosorio

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

http://svn.digium.com/view/asterisk?view=rev&revision=205696
By: Digium Subversion (svnbot) 2009-07-09 16:26:01

Repository: asterisk
Revision: 205697

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_fax.c
U   branches/1.6.0/channels/chan_sip.c
U   branches/1.6.0/include/asterisk/frame.h

------------------------------------------------------------------------
r205697 | kpfleming | 2009-07-09 16:26:01 -0500 (Thu, 09 Jul 2009) | 23 lines

Merged revisions 205696 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines
 
 Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.
 
 Recent changes in T.38 negotiation in Asterisk caused these applications to
 not respond when the other endpoint initiated a switchover to T.38; this
 resulted in the T.38 switchover failing, and the FAX attempt to be made
 using an audio connection, instead of T.38 (which would usually cause the
 FAX to fail completely).
 
 This patch corrects this problem, and the applications will now correctly
 respond to the T.38 switchover request. In addition, the response will include
 the appopriate T.38 session parameters based on what the other end offered
 and what our end is capable of.
 
 (closes issue ASTERISK-13915)
 Reported by: afosorio
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=205697
By: Digium Subversion (svnbot) 2009-07-09 16:27:19

Repository: asterisk
Revision: 205698

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_fax.c
U   branches/1.6.1/channels/chan_sip.c
U   branches/1.6.1/include/asterisk/frame.h

------------------------------------------------------------------------
r205698 | kpfleming | 2009-07-09 16:27:19 -0500 (Thu, 09 Jul 2009) | 23 lines

Merged revisions 205696 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines
 
 Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.
 
 Recent changes in T.38 negotiation in Asterisk caused these applications to
 not respond when the other endpoint initiated a switchover to T.38; this
 resulted in the T.38 switchover failing, and the FAX attempt to be made
 using an audio connection, instead of T.38 (which would usually cause the
 FAX to fail completely).
 
 This patch corrects this problem, and the applications will now correctly
 respond to the T.38 switchover request. In addition, the response will include
 the appopriate T.38 session parameters based on what the other end offered
 and what our end is capable of.
 
 (closes issue ASTERISK-13915)
 Reported by: afosorio
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=205698
By: Digium Subversion (svnbot) 2009-07-09 16:27:37

Repository: asterisk
Revision: 205699

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_fax.c
U   branches/1.6.2/channels/chan_sip.c
U   branches/1.6.2/include/asterisk/frame.h

------------------------------------------------------------------------
r205699 | kpfleming | 2009-07-09 16:27:36 -0500 (Thu, 09 Jul 2009) | 23 lines

Merged revisions 205696 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines
 
 Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.
 
 Recent changes in T.38 negotiation in Asterisk caused these applications to
 not respond when the other endpoint initiated a switchover to T.38; this
 resulted in the T.38 switchover failing, and the FAX attempt to be made
 using an audio connection, instead of T.38 (which would usually cause the
 FAX to fail completely).
 
 This patch corrects this problem, and the applications will now correctly
 respond to the T.38 switchover request. In addition, the response will include
 the appopriate T.38 session parameters based on what the other end offered
 and what our end is capable of.
 
 (closes issue ASTERISK-13915)
 Reported by: afosorio
........

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

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