[Freeswitch-users] T.38 Issues with passthrough handshaking

Johannes Jakob jjj at 3js.de
Thu Feb 24 19:44:06 MSK 2011


Hi,

I'm having some serious trouble getting outbound t38 passthru to work in the following scenario:

SIP Upstream <> FreeSWITCH <> Asterisk <> SIP ATA <> analog fax

I'm not sure if it's a plain FS problem, but I have to start somewhere and I found at least one problem (I think) with FS's behaviour when negotiating with the gateway.

Inbound T.38 faxes, when the ATA has to do the reinvite, work perfectly fine from one end to the other.

Outbound faxes on the other hand, don't work at all.

Here are the important config parts:

dialplan before bridging to gateway:
      <action application="export" data="t38_passthru=true"/>
      <action application="set" data="proxy_media=true"/>
      <action application="set" data="bypass_media=false"/>

directory-entry for the asterisk-registration:
      <param name="t38-passthru" value="true"/>
and
      <variable name="proxy_media" value="true"/>
      <variable name="bypass_media" value="false"/>

and finally the gateway's sip_profile:
  <param name="t38-passthru" value="true"/>
  <param name="inbound-proxy-media" value="true"/>

So much for introduction... When trying to send a fax to 017286483798, this is what happens on the SBC:


asterisk "client" is sending the plain audio INVITE to SBC:
-----------------------------------------------------------------------------------------------------------------------
9	37.668216	10.16.139.28	10.16.133.66	SIP/SDP	1202	Request: INVITE sip:017286483798 at sbc1.mysip.net, with session description
AkE`b?FG^^B%INVITE sip:017286483798 at sbc1.mysip.net SIP/2.0
Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec
Max-Forwards: 70
From: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
To: <sip:017286483798 at sbc1.mysip.net>
Contact: <sip:0692386432 at 10.16.139.28:5060>
Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
CSeq: 103 INVITE
User-Agent: FPBX-2.8.1(1.8.2.4)
Proxy-Authorization: Digest username="sipuser", realm="mysip.net", algorithm=MD5, uri="sip:017286483798 at sbc1.mysip.net", nonce="aa9339fc-9e53-4017-85ff-fac5367cb733", response="96f4dea7267d436779cd106947cc25b7", qop=auth, cnonce="4e110d27", nc=00000001
Date: Thu, 24 Feb 2011 07:30:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 285

v=0
o=root 1297612317 1297612318 IN IP4 10.16.139.28
s=Asterisk PBX 1.8.2.4
c=IN IP4 10.16.139.28
t=0 0
m=audio 15000 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
-----------------------------------------------------------------------------------------------------------------------

SBC is forwarding the request to the correct gateway:
-----------------------------------------------------------------------------------------------------------------------
11	37.716704	10.16.133.66	10.15.12.215	SIP/SDP	1232	Request: INVITE sip:+4317286483798 at 10.15.12.215, with session description
=|$E%@^BWB{INVITE sip:+4317286483798 at 10.15.12.215 SIP/2.0
Via: SIP/2.0/UDP 10.16.133.66:5080;rport;branch=z9hG4bK33eQ6Na9D991D
Max-Forwards: 69
From: "0692386432" <sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
To: <sip:+4317286483798 at 10.15.12.215>
Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
CSeq: 8930272 INVITE
Contact: <sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19 23-38-04 +0100
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 269
X-FS-Support: update_display
Remote-Party-ID: "0692386432" <sip:0692386432 at 10.16.133.66>;party=calling;screen=yes;privacy=off
P-Asserted-Identity: <sip:06923864320 at sip.gateway.de>

v=0
o=FreeSWITCH 3022782041 3022782042 IN IP4 10.16.133.66
s=FreeSWITCH
c=IN IP4 10.16.133.66
t=0 0
m=audio 18446 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
-----------------------------------------------------------------------------------------------------------------------

Gatway says, everything OK, audio call patched through:
-----------------------------------------------------------------------------------------------------------------------
22	39.760159	10.15.12.215	10.16.133.66	SIP/SDP	750	Status: 200 OK, with session description
AkEw	W^BSIP/2.0 200 OK
Via: SIP/2.0/UDP 10.16.133.66:5080;branch=z9hG4bK33eQ6Na9D991D;rport=5080
Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
From: "0692386432"<sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
To: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
CSeq: 8930272 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: <sip:10.15.12.215:5060;user=phone>
Content-Length: 217
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 3014926 3014927 IN IP4 10.15.12.215
s=Sip Call
c=IN IP4 10.15.12.215
t=0 0
m=audio 15490 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=fmtp:101 0-15
-----------------------------------------------------------------------------------------------------------------------

SBC is telling the asterisk box, everything is fine
-----------------------------------------------------------------------------------------------------------------------
28	39.770349	10.16.133.66	10.16.139.28	SIP/SDP	1185	Status: 200 OK, with session description
=|$Ew at 1y^B^}aSIP/2.0 200 OK
Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec
From: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
To: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
CSeq: 103 INVITE
Contact: <sip:017286483798 at 10.16.133.66:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19 23-38-04 +0100
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
Remote-Party-ID: "017286483798" <sip:017286483798 at 10.16.133.66>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 3022845683 3022845684 IN IP4 10.16.133.66
s=FreeSWITCH
c=IN IP4 10.16.133.66
t=0 0
m=audio 28850 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
-----------------------------------------------------------------------------------------------------------------------

so, after the ACK which is passed along as well, there is the typical audio stuff, ringing... in both directions the right, pre-negotiated udp ports, everything is fine so far:
-----------------------------------------------------------------------------------------------------------------------
45	39.849484	10.15.12.215	10.16.133.66	RTP	216	PT=ITU-T G.711 PCMU, SSRC=0x727E59A0, Seq=23045, Time=3032460352 
User Datagram Protocol, Src Port: 15490 (15490), Dst Port: 18446 (18446)
-----------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------
46	39.849541	10.16.133.66	10.16.139.28	RTP	216	PT=ITU-T G.711 PCMU, SSRC=0x727E59A0, Seq=23045, Time=3032460352 
User Datagram Protocol, Src Port: 28850 (28850), Dst Port: hydap (15000)
-----------------------------------------------------------------------------------------------------------------------

Now, the magic happens, the gateway is sending it's T.38 re-INVITE to establish better fax connectivity... well, let's see what happens:

The gateway is suggesting to move the audio stuff from port 15490 to 15492, and instead speak t38/udptl on port 15490, keep that in mind.

-----------------------------------------------------------------------------------------------------------------------
2099	50.121304	10.15.12.215	10.16.133.66	SIP/SDP	1026	Request: INVITE sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description
AkEW^BwINVITE sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1 SIP/2.0
Via: SIP/2.0/UDP 10.15.12.215:5060;branch=z9hG4bK4abf7e790396e9d932f59632f
Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
From: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
To: "0692386432"<sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
CSeq: 2 INVITE
Max-Forwards: 69
Contact: <sip:10.15.12.215:5060>
Content-Length: 527
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 3014926 3014928 IN IP4 10.15.12.215
s=Sip Call
c=IN IP4 10.15.12.215
t=0 0
m=image 15490 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 15492 RTP/AVP 8 0 127 103 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:127 PCMU/8000
a=gpmd:127 vbd=yes
a=rtpmap:103 PCMA/8000
a=gpmd:103 vbd=yes
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
a=fmtp:101 0-15
-----------------------------------------------------------------------------------------------------------------------

FS is handing this INVITE to asterisk (and tells asterisk, it would accept audio and/or t.38, both on the same port 28850, don't think that's a problem, but it's at least different from HuaweiSoftX3000's behavior):

-----------------------------------------------------------------------------------------------------------------------
2101	50.122833	10.16.133.66	10.16.139.28	SIP/SDP	1398	Request: INVITE sip:0692386432 at 10.16.139.28:5060, in-dialog, with session description
=|$Efw at 0^B^R6INVITE sip:0692386432 at 10.16.139.28:5060 SIP/2.0
Via: SIP/2.0/UDP 10.16.133.66;rport;branch=z9hG4bKy5perv1F90acS
Max-Forwards: 70
From: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
To: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
CSeq: 8930278 INVITE
Contact: <sip:017286483798 at 10.16.133.66:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19 23-38-04 +0100
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 532
X-FS-Support: update_display
P-Asserted-Identity: <sip:06923864320 at sip.gateway.de>

v=0
o=FreeSWITCH 3022845683 3022845685 IN IP4 10.16.133.66
s=FreeSWITCH
c=IN IP4 10.16.133.66
t=0 0
m=image 28850 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 28850 RTP/AVP 8 0 127 103 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:127 PCMU/8000
a=rtpmap:103 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=gpmd:127 vbd=yes
a=gpmd:103 vbd=yes
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
-----------------------------------------------------------------------------------------------------------------------

The asterisk box says this is fine (after of course successfully talking to the ATA, which is fine with it, too, but want's to have slower speed). The asterisk box is also changing the port it wants to get t38 data on from 15508 to 4676 and finally sets the udp port for audio 0 to disable it.
Just plain t.38 in the new SDP description:

-----------------------------------------------------------------------------------------------------------------------
2107	50.165366	10.16.139.28	10.16.133.66	SIP/SDP	920	Status: 200 OK, with session description
AkE`b?G^^^BtAbSIP/2.0 200 OK
Via: SIP/2.0/UDP 10.16.133.66;branch=z9hG4bKy5perv1F90acS;received=10.16.133.66;rport=5060
From: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
To: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
CSeq: 8930278 INVITE
Server: FPBX-2.8.1(1.8.2.4)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:0692386432 at 10.16.139.28:5060>
Content-Type: application/sdp
Content-Length: 307

v=0
o=root 1297612317 1297612319 IN IP4 10.16.139.28
s=Asterisk PBX 1.8.2.4
c=IN IP4 10.16.139.28
t=0 0
m=audio 0 RTP/AVP 8 0 127 103 101
m=image 4676 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:397
a=T38FaxUdpEC:t38UDPRedundancy
-----------------------------------------------------------------------------------------------------------------------

BUT look at this! What does FreeSWITCH tell the gateway???
It sends 200 OK, but suddenly wants to receive only audio data and disables comfort noise?
Same udp port as before, but no sign of t.38 in the SDP description!

-----------------------------------------------------------------------------------------------------------------------
2111	50.170760	10.16.133.66	10.15.12.215	SIP/SDP	902	Status: 200 OK, with session description
=|$Ev%@^BWbA1SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.15.12.215:5060;branch=z9hG4bK4abf7e790396e9d932f59632f
From: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
To: "0692386432" <sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
CSeq: 2 INVITE
Contact: <sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1>
User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19 23-38-04 +0100
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 168

v=0
o=FreeSWITCH 3022782041 3022782043 IN IP4 10.16.133.66
s=FreeSWITCH
c=IN IP4 10.16.133.66
t=0 0
m=audio 18446 RTP/AVP 8 0 127 103 101
m=audio 0 RTP/AVP 19
-----------------------------------------------------------------------------------------------------------------------

and look at this, even though we just told the gateway to only talk audio to it, we send a t38 packet! (it's this lonely one though!)

-----------------------------------------------------------------------------------------------------------------------
2112	50.174592	94.186.133.66	87.234.1.215	T.38	216	UDP: UDPTLPacket Seq=32768  t30ind: <unknown>[UNKNOWN PER: 10.9.3.8.1][Malformed Packet]
User Datagram Protocol, Src Port: 18446 (18446), Dst Port: 15490 (15490)
-----------------------------------------------------------------------------------------------------------------------


The gateway keeps sending normal audio to us on the specified and unchanged port, BUT from the udp port it originally told us it would only accept t.38 on... 

-----------------------------------------------------------------------------------------------------------------------
2260	51.589980	10.15.12.215	10.16.133.66	RTP	216	PT=ITU-T G.711 PCMA, SSRC=0x727E59A0, Seq=23634, Time=3032554272 
User Datagram Protocol, Src Port: 15490 (15490), Dst Port: 18446 (18446)
-----------------------------------------------------------------------------------------------------------------------

While the gateway is sending us plain audio, we are talking t38 to  the asterisk box (which is not responding).
-----------------------------------------------------------------------------------------------------------------------
2261	51.590063	10.16.133.66	10.16.139.28	T.38	216	UDP: UDPTLPacket Seq=32776  data:v8:[UNKNOWN PER: too long integer(per_integer)][Malformed Packet]
User Datagram Protocol, Src Port: 28850 (28850), Dst Port: dhct-alerts (4676)
-----------------------------------------------------------------------------------------------------------------------



For the record, on the asterisk (version 1.8.2.4) box I defined
 t38pt_udptl=yes,redundancy
 directmedia=no
for the gateways and the ATA's extension.

On both, the sbc and the asterisk box I compiled res_fax_spandsp, mod_spandsp with spandsp-0.0.6pre18.

So... I've been spending far tooooo much time debugging this and I'm quite sure I'm just too stupid to find a solution for this.


Is there any good pcap anonymizing utitlity, that can substitute application layer stuff as well?

Well, *any* help/hint would be appreciated very much ;)

Thanks in advance,

  John


More information about the FreeSWITCH-users mailing list