WRP400 T.38 Inbound Fax Failure due to early BYE from WRP400

jjcinaz42 · ‎07-30-2009

We are attempting to certify the WRP400 as a new acceptable SIP device for our VoIP services. We have voice running fine and T.38 outbound faxing (from WRP400 to PSTN) working just fine. We are having an issue with T.38 inbound to WRP400. The gateway (a Mediatrix 3531 in this case) and the WRP400 both switch into T.38 mode just fine. Here is the Reinvite to get into T.38 mode from the gateway to the WRP400:

INVITE sip:wag400-1@192.168.8.149:5060 SIP/2.0
Via: SIP/2.0/UDP 1.1.1.5:5060;branch=z9hG4bK7cdaf842;rport
From: "5405551234" <sip:abcd@xxxx.com>;tag=as5e5bf674
To: <sip:wag400-1@192.168.8.149:5060>;tag=f45bfcca81dff200i0
Contact: <sip:abcd@1.1.1.55>
Call-ID: 156a0e24750dbdfb2365a88e62c0aded@xxxx.com
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 347

v=0
o=root 8710 8711 IN IP4 1.1.1.55
s=session
c=IN IP4 1.1.1.55
t=0 0
m=image 4628 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

The WRP400 replies with:

SIP/2.0 200 OK
To: <sip:wag400-1@192.168.8.149:5060>;tag=f45bfcca81dff200i0
From: "5405551234" <sip:abcd@xxxx.com>;tag=as5e5bf674
Call-ID: 156a0e24750dbdfb2365a88e62c0aded@xxxx.com
CSeq: 103 INVITE
Via: SIP/2.0/UDP 1.1.1.55:5060;branch=z9hG4bK7cdaf842
Contact: wag400-1 <sip:wag400-1@192.168.8.149:5060>
Server: Linksys/WRP400-1.01.00
Content-Length: 265
Content-Type: application/sdp

v=0
o=- 44668 44668 IN IP4 192.168.8.149
s=-
c=IN IP4 192.168.8.149
t=0 0
m=image 16426 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:200
a=T38FaxUdpEC:t38UDPRedundancy

The sending fax device sends a page, but at the end of the page data, the WRP400 sends a BYE message when it isn't supposed to:

1.1.1.55 192.168.8.149 T.38 UDP: UDPTLPacket Seq=00617 data:v17-14400: hdlc-sig-end

1.1.1.55 192.168.8.149 T.38 UDP: UDPTLPacket Seq=00618 t30ind: v21-preamble

192.168.8.149 64.119.32.55 SIP Request: BYE sip:5405551234@1.1.1.55

1.1.1.55 192.168.8.149 SIP Status: 200 OK

The WRP400 seems to cut off the communications before the PPS (partial page signal) and MCF (message confirmation) can be sent between the fax devices.

A debug output from the WRP400 is as follows:

<159>pconly: 0 in 30-Jul 14:13:41.77 from 192.168.8.149
<159>n: 2 in 30-Jul 14:13:41.77 from 192.168.8.149
<159>clRemote: 0xbddffaa0, clLocal->ucNumAudioCodec: 3 in 30-Jul 14:13:41.77 from 192.168.8.149
<151>[0:0]AUD ALLOC CALL (port=16432) in 30-Jul 14:13:41.77 from 192.168.8.149
<151>[0:0]RTP Rx Up in 30-Jul 14:13:41.78 from 192.168.8.149
<159>[0]Off Hook in 30-Jul 14:13:50.66 from 192.168.8.149
<151>CC:Connected in 30-Jul 14:13:50.67 from 192.168.8.149
<151>[0:0]ENC INIT 0 in 30-Jul 14:13:50.67 from 192.168.8.149
<151>[0:0]RTP Tx Up (pt=0->37207740:13486) in 30-Jul 14:13:50.67 from 192.168.8.149
<151>[0:0]RTCP Tx Up in 30-Jul 14:13:50.67 from 192.168.8.149
<159>[0:0]RTP Rx 1st PKT @16432(2) in 30-Jul 14:13:50.73 from 192.168.8.149
<151>[0:0]DEC INIT 0 in 30-Jul 14:13:50.80 from 192.168.8.149
<159>[0:0]CC:ALLOC T38 0 in 30-Jul 14:13:52.16 from 192.168.8.149
<134>SIP:Peer Request T38 in 30-Jul 14:13:52.16 from 192.168.8.149
<134>SIP:Peer Request T38 in 30-Jul 14:13:52.16 from 192.168.8.149
<151>[0:0]RTP Tx Dn in 30-Jul 14:13:52.16 from 192.168.8.149
<151>[0:0]RTP Rx Dn in 30-Jul 14:13:52.17 from 192.168.8.149
<78> cron[338]: (root) CMD (/sbin/check_ps) in 30-Jul 14:14:0.75 from 192.168.8.149
<159>[0]On Hook in 30-Jul 14:14:48.95 from 192.168.8.149
<134>[0]AUD:FtlCloseSession:0 in 30-Jul 14:14:48.95 from 192.168.8.149
<134>[0]AUD:FtlCloseSession:0 in 30-Jul 14:14:48.95 from 192.168.8.149
<151>[0:0]AUD Rel Call in 30-Jul 14:14:48.95 from 192.168.8.149
<151>DLG Terminated 19beb8 in 30-Jul 14:14:48.95 from 192.168.8.149
<151>Sess Terminated in 30-Jul 14:14:48.97 from 192.168.8.149

You can see where it switches into T.38 mode, but I don't see any debug indicating why the call was dropped. Some packet captures have shown a call drop at other times, but most are at the end of the page. This is version version 1.01.00. Any clues as to what is happening and how to fix it?

Thanks,
Joe

Alberto Montilla · ‎08-25-2009

Dear Sir;

Can you please send the full trace file via a private message. Syslog traces from the WRP400 would help also. It is likely that WRP400 is sending the BYE message because it is not receiving packets from the other end.

Regards
Alberto

Carlosceka · ‎12-11-2009

Dear Alberto:

I am having issues setting up my ata (WRP400) with my freebpx (linux/trixbox) for a fax extension.

I am looking for help and this is the closest I got in my search.

Maybe you can help me be sending me instructions on how to setup the Line1 parameters to work with a standard fax machine.

The simptom is the fax dials a fax line and don't get triggered and when receiving a call the fax machine don't pick up the call.

I am attaching a document with screenshots with current configuration.

I will realy appreciate your help,

Regards,

Carlos

Alberto Montilla · ‎12-15-2009

Dear Carlos;

This should work out of the box. What type of fax machine are you trying to connect?

regards
Alberto

Carlosceka · ‎12-17-2009

I performed a full reset.

I setup only the sip account I need (only one) by providing SUSCRIBER INFORMATION only,. the rest all by default.

The fax I am using is a brother multifuntion, that was running perfectly (fax in and out) at home with a cisco 2 voip ATA device provided and linked to Ringcentral service.

The fax picks the line, gets dial tone, and keeps beeping. The fax at the other end receives the call but dont' give fax signal.

When I hook up a regular phone to the fax (second phone port of the fax) I can dial other extension and there is a delay for 15 seconds until start ringing.

the WRP400 is linked to a Freepbx.

Please help, and thanks..

Carlos

jjcinaz42 · ‎01-19-2010

This issue has been fixed. It was caused by an improper UDPTL datagram size negotiation while Asterisk was the B2BUA and the two opposing devices were using different UDPTL sizes (the WRP400 and Mediatrix 3531 in this case). To get this working, you need the lastest version of Asterisk 1.6.1.x or 1.6.2.x. The symptom on being able to send and not receive on the unit is what you would see in this case as well.