T.38 Issues with passthrough handshaking
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@sbc1.mysip.net, with session description AkE`b?FG^^B%INVITE sip:017286483798@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@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net> Contact: <sip:0692386432@10.16.139.28:5060> Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215, with session description =|$E%@^BWB{INVITE sip:+4317286483798@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@10.15.12.215> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 8930272 INVITE Contact: <sip:gw+gateway1@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@10.16.133.66>;party=calling;screen=yes;privacy=off P-Asserted-Identity: <sip:06923864320@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@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@1y^B^}aSIP/2.0 200 OK Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec From: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net>;tag=crS25Ur70m0BK Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 103 INVITE Contact: <sip:017286483798@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@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@10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description AkEW^BwINVITE sip:gw+gateway1@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432"<sip:0692386432@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@10.16.139.28:5060, in-dialog, with session description =|$Efw@0^B^R6INVITE sip:0692386432@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 8930278 INVITE Contact: <sip:017286483798@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@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432" <sip:0692386432@10.16.133.66>;tag=4NH77aQN2v7ZS Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 2 INVITE Contact: <sip:gw+gateway1@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
Hi again, Just a short followup: originating a tif file directly on the FS (txfax) does work, trying to send the same tif file from the asterisk with SendFax doesn't. Full traces (sorry, just ascii, no pcap, but I had to sanitize them somehow) of all three test cases, for those having the time and willing to help, can be found here: http://www.3js.de/debug.tgz According to how few people are complaining, it must be quite simple to get t38 working... am I blind or just too stupid to see my errors? Thanks a lot for any hint in the right direction! Best regards, John On 24.02.2011, at 17:44, Johannes Jakob wrote:
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@sbc1.mysip.net, with session description AkE`b?FG^^B%INVITE sip:017286483798@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@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net> Contact: <sip:0692386432@10.16.139.28:5060> Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215, with session description =|$E%@^BWB{INVITE sip:+4317286483798@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@10.15.12.215> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 8930272 INVITE Contact: <sip:gw+gateway1@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@10.16.133.66>;party=calling;screen=yes;privacy=off P-Asserted-Identity: <sip:06923864320@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@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@1y^B^}aSIP/2.0 200 OK Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec From: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net>;tag=crS25Ur70m0BK Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 103 INVITE Contact: <sip:017286483798@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@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@10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description AkEW^BwINVITE sip:gw+gateway1@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432"<sip:0692386432@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@10.16.139.28:5060, in-dialog, with session description =|$Efw@0^B^R6INVITE sip:0692386432@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 8930278 INVITE Contact: <sip:017286483798@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@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432" <sip:0692386432@10.16.133.66>;tag=4NH77aQN2v7ZS Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 2 INVITE Contact: <sip:gw+gateway1@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
<!-- you only need to set this on lastest builds of FS --> <action application="export" data="t38_passthru=true"/> <!-- you don't mix t38_passthru with proxy media get rid of these completely --> <!-- <action application="set" data="proxy_media=true"/> <action application="set" data="bypass_media=false"/>--> Maybe someday you'll be brave and try terminating the t38 right to FS instead. BTW it seems like whatever is generating your sip trace has a bug in it, there are garbage characters before each sip message unless its printing unfiltered network packets or something. On Thu, Feb 24, 2011 at 4:37 PM, Johannes Jakob <jjj@3js.de> wrote:
Hi again,
Just a short followup:
originating a tif file directly on the FS (txfax) does work, trying to send the same tif file from the asterisk with SendFax doesn't.
Full traces (sorry, just ascii, no pcap, but I had to sanitize them somehow) of all three test cases, for those having the time and willing to help, can be found here:
According to how few people are complaining, it must be quite simple to get t38 working... am I blind or just too stupid to see my errors?
Thanks a lot for any hint in the right direction!
Best regards,
John
On 24.02.2011, at 17:44, Johannes Jakob wrote:
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@sbc1.mysip.net, with session description AkE`b?FG^^B%INVITE sip:017286483798@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@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net> Contact: <sip:0692386432@10.16.139.28:5060> Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215, with session description =|$E%@^BWB{INVITE sip:+4317286483798@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@10.15.12.215> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 8930272 INVITE Contact: <sip:gw+gateway1@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@10.16.133.66>;party=calling;screen=yes;privacy=off P-Asserted-Identity: <sip:06923864320@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@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@1y^B^}aSIP/2.0 200 OK Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec From: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net>;tag=crS25Ur70m0BK Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 103 INVITE Contact: <sip:017286483798@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@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@10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description AkEW^BwINVITE sip:gw+gateway1@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432"<sip:0692386432@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@10.16.139.28:5060, in-dialog, with session description =|$Efw@0^B^R6INVITE sip:0692386432@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 8930278 INVITE Contact: <sip:017286483798@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@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432" <sip:0692386432@10.16.133.66>;tag=4NH77aQN2v7ZS Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 2 INVITE Contact: <sip:gw+gateway1@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
_______________________________________________ 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, hi everyone, Your help is very appreciated, thank you very much! I'm really getting mad with all those T.38 stuff. weeks and weeks of troubleshooting and try and error - yes, I don't really understand t.38... On 25.02.2011, at 00:04, Anthony Minessale wrote:
<!-- you only need to set this on lastest builds of FS --> <action application="export" data="t38_passthru=true"/>
Okay, thanks for this hint, the wiki suggests proxy_media... as soon as I'll get this stuff working, I'll add my experiences with my (little) insights.
<!-- you don't mix t38_passthru with proxy media get rid of these completely -->
I've done that... removed any proxy_media stuff in all profiles/dialplans. I'm still not getting anywhere... incoming fax is still working, but outbound faxing still is not possible. I put up a flow-chart (by wireshark) and a dump of the relevant re-invite and 200OK packets here; http://www.3js.de/20110301/ As far as I can see, ports get negotiated just fine, and the fax is being sent, but somehow this looks like a monolog... Even though it looks like the fax itself is being sent fine, there is no fax received on the other side and my fax reports an error and unsent fax. PLEASE have a quick look at those, I'm quite desperate...
Maybe someday you'll be brave and try terminating the t38 right to FS instead.
Hmm, if I understand this right, you would suggest to terminate the outgoing fax on the FS: Upstream <(a)> FS <(b)> asterisk <(c)> SIP ATA The fax is being sent by ATA via plain Audio (c) to the asterisk box, which is passing it along to FS as plain audio (b). Now you'd like me to let FS send the reinvite back to the asterisk box? That means, according to the wiki I'd have to do: <extension name="t38_reinvite"> <condition> <action application="set" data="fax_enable_t38=true"/> <action application="set" data="fax_enable_t38_request=true"/> <action application="set" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/1234@host"/> </condition> </extension> But what happens for the B-leg, going out to the my upstream? There will be a t.38 reinvite as well, coming from the Upstream... won't that be a problem / a more complicated system then needed? Why would you prefer this over passthru?
BTW it seems like whatever is generating your sip trace has a bug in it, there are garbage characters before each sip message unless its printing unfiltered network packets or something.
tcpdump -A -s0 -w file.pcap tcpdump -An -r file.pcap > plain.txt That had to be done so I could replace sensible stuff with fake data.... Thanks again for your help so far! Best regards, John
On Thu, Feb 24, 2011 at 4:37 PM, Johannes Jakob <jjj@3js.de> wrote:
Hi again,
Just a short followup:
originating a tif file directly on the FS (txfax) does work, trying to send the same tif file from the asterisk with SendFax doesn't.
Full traces (sorry, just ascii, no pcap, but I had to sanitize them somehow) of all three test cases, for those having the time and willing to help, can be found here:
According to how few people are complaining, it must be quite simple to get t38 working... am I blind or just too stupid to see my errors?
Thanks a lot for any hint in the right direction!
Best regards,
John
On 24.02.2011, at 17:44, Johannes Jakob wrote:
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@sbc1.mysip.net, with session description AkE`b?FG^^B%INVITE sip:017286483798@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@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net> Contact: <sip:0692386432@10.16.139.28:5060> Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215, with session description =|$E%@^BWB{INVITE sip:+4317286483798@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@10.15.12.215> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 8930272 INVITE Contact: <sip:gw+gateway1@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@10.16.133.66>;party=calling;screen=yes;privacy=off P-Asserted-Identity: <sip:06923864320@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@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@1y^B^}aSIP/2.0 200 OK Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec From: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net>;tag=crS25Ur70m0BK Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 103 INVITE Contact: <sip:017286483798@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@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@10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description AkEW^BwINVITE sip:gw+gateway1@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432"<sip:0692386432@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@10.16.139.28:5060, in-dialog, with session description =|$Efw@0^B^R6INVITE sip:0692386432@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 8930278 INVITE Contact: <sip:017286483798@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@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432" <sip:0692386432@10.16.133.66>;tag=4NH77aQN2v7ZS Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 2 INVITE Contact: <sip:gw+gateway1@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
_______________________________________________ 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
_______________________________________________ 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
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
----- Original Message ----- From: "Johannes Jakob" <jjj@3js.de> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, March 01, 2011 11:27 AM Subject: Re: [Freeswitch-users] T.38 Issues with passthrough handshaking
Hi Anthony, hi everyone,
Your help is very appreciated, thank you very much! I'm really getting mad with all those T.38 stuff. weeks and weeks of troubleshooting and try and error - yes, I don't really understand t.38...
On 25.02.2011, at 00:04, Anthony Minessale wrote:
<!-- you only need to set this on lastest builds of FS --> <action application="export" data="t38_passthru=true"/>
Okay, thanks for this hint, the wiki suggests proxy_media... as soon as I'll get this stuff working, I'll add my experiences with my (little) insights.
<!-- you don't mix t38_passthru with proxy media get rid of these completely -->
I've done that... removed any proxy_media stuff in all profiles/dialplans.
I'm still not getting anywhere... incoming fax is still working, but outbound faxing still is not possible.
I put up a flow-chart (by wireshark) and a dump of the relevant re-invite and 200OK packets here;
As far as I can see, ports get negotiated just fine, and the fax is being sent, but somehow this looks like a monolog... Even though it looks like the fax itself is being sent fine, there is no fax received on the other side and my fax reports an error and unsent fax.
PLEASE have a quick look at those, I'm quite desperate...
Maybe someday you'll be brave and try terminating the t38 right to FS instead.
Hmm, if I understand this right, you would suggest to terminate the outgoing fax on the FS:
Upstream <(a)> FS <(b)> asterisk <(c)> SIP ATA
The fax is being sent by ATA via plain Audio (c) to the asterisk box, which is passing it along to FS as plain audio (b). Now you'd like me to let FS send the reinvite back to the asterisk box? That means, according to the wiki I'd have to do:
<extension name="t38_reinvite"> <condition> <action application="set" data="fax_enable_t38=true"/> <action application="set" data="fax_enable_t38_request=true"/> <action application="set" data="execute_on_answer=t38_gateway self"/> <action application="bridge" data="sofia/external/1234@host"/> </condition> </extension>
But what happens for the B-leg, going out to the my upstream? There will be a t.38 reinvite as well, coming from the Upstream... won't that be a problem / a more complicated system then needed? Why would you prefer this over passthru?
BTW it seems like whatever is generating your sip trace has a bug in it, there are garbage characters before each sip message unless its printing unfiltered network packets or something.
tcpdump -A -s0 -w file.pcap tcpdump -An -r file.pcap > plain.txt That had to be done so I could replace sensible stuff with fake data....
Thanks again for your help so far!
Best regards,
John
On Thu, Feb 24, 2011 at 4:37 PM, Johannes Jakob <jjj@3js.de> wrote:
Hi again,
Just a short followup:
originating a tif file directly on the FS (txfax) does work, trying to send the same tif file from the asterisk with SendFax doesn't.
Full traces (sorry, just ascii, no pcap, but I had to sanitize them somehow) of all three test cases, for those having the time and willing to help, can be found here:
According to how few people are complaining, it must be quite simple to get t38 working... am I blind or just too stupid to see my errors?
Thanks a lot for any hint in the right direction!
Best regards,
John
On 24.02.2011, at 17:44, Johannes Jakob wrote:
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@sbc1.mysip.net, with session description AkE`b?FG^^B%INVITE sip:017286483798@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@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net> Contact: <sip:0692386432@10.16.139.28:5060> Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215, with session description =|$E%@^BWB{INVITE sip:+4317286483798@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@10.15.12.215> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 8930272 INVITE Contact: <sip:gw+gateway1@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@10.16.133.66>;party=calling;screen=yes;privacy=off P-Asserted-Identity: <sip:06923864320@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@10.16.133.66>;tag=4NH77aQN2v7ZS To: <sip:+4317286483798@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@1y^B^}aSIP/2.0 200 OK Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec From: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 To: <sip:017286483798@sbc1.mysip.net>;tag=crS25Ur70m0BK Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 103 INVITE Contact: <sip:017286483798@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@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@10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog, with session description AkEW^BwINVITE sip:gw+gateway1@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432"<sip:0692386432@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@10.16.139.28:5060, in-dialog, with session description =|$Efw@0^B^R6INVITE sip:0692386432@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@mysip.net CSeq: 8930278 INVITE Contact: <sip:017286483798@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@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@sbc1.mysip.net>;tag=crS25Ur70m0BK To: "0692386432" <sip:0692386432@mysip.net>;tag=as235c17b6 Call-ID: 6de3237b20a96ab010fb9b3f2436d305@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@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@10.15.12.215>;tag=h1hl6tsu-CC-39 To: "0692386432" <sip:0692386432@10.16.133.66>;tag=4NH77aQN2v7ZS Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180 CSeq: 2 INVITE Contact: <sip:gw+gateway1@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
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
hehe, thank you, but I'm fully aware of who Anthony is and I *do* in fact fully trust him in all things FreeSWITCH ;) sorry if my badly chosen words imply I wouldn't! All I wanted to say is, that the setup I had done and described in my first posting has been done after reading Anthony's, Michael's and Darren's book and lots and lots of wiki pages and mailing list postings. In the past it seems to have been necessary to use proxy_media and disable bypass manually, so I had done that, not knowing this is deprecated. So, if anybody of you FreeSWITCH wizards has ANY idea on how to get my setup working, I'd be very very *very* happy.... I love FreeSWITCH for it's clean and organized structure, it's flexibility and speed.... but t.38 drives me crazy... and that's of course NOT FreeSWITCH's fault! Thanks to everybody who has time and willing to read my debugging stuff! And of course sorry to Anthony, if I by any means disrespected you with my bad english! ;) Greetings, John
since the implementation of T38 you should set proxy_media to false and bypass_media to false also.... ----- Original Message ----- From: "Johannes Jakob" <jjj@3js.de> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, March 01, 2011 12:09 PM Subject: Re: [Freeswitch-users] T.38 Issues with passthrough handshaking
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
hehe, thank you, but I'm fully aware of who Anthony is and I *do* in fact fully trust him in all things FreeSWITCH ;) sorry if my badly chosen words imply I wouldn't!
All I wanted to say is, that the setup I had done and described in my first posting has been done after reading Anthony's, Michael's and Darren's book and lots and lots of wiki pages and mailing list postings. In the past it seems to have been necessary to use proxy_media and disable bypass manually, so I had done that, not knowing this is deprecated.
So, if anybody of you FreeSWITCH wizards has ANY idea on how to get my setup working, I'd be very very *very* happy....
I love FreeSWITCH for it's clean and organized structure, it's flexibility and speed.... but t.38 drives me crazy... and that's of course NOT FreeSWITCH's fault!
Thanks to everybody who has time and willing to read my debugging stuff!
And of course sorry to Anthony, if I by any means disrespected you with my bad english! ;)
Greetings, John _______________________________________________ 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 need to get traces from the FreeSWITCH console more than a pcap. Execute these commands on the cli: (don't forget any I often have to tell people to take traces more than once) sofia global siptrace on console loglevel debug Reproduce the problem situation then paste that log. Every new time something changes, repeat this step. On Tue, Mar 1, 2011 at 11:18 AM, Madovsky <infos@madovsky.org> wrote:
since the implementation of T38 you should set proxy_media to false and bypass_media to false also....
----- Original Message ----- From: "Johannes Jakob" <jjj@3js.de> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, March 01, 2011 12:09 PM Subject: Re: [Freeswitch-users] T.38 Issues with passthrough handshaking
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
hehe, thank you, but I'm fully aware of who Anthony is and I *do* in fact fully trust him in all things FreeSWITCH ;) sorry if my badly chosen words imply I wouldn't!
All I wanted to say is, that the setup I had done and described in my first posting has been done after reading Anthony's, Michael's and Darren's book and lots and lots of wiki pages and mailing list postings. In the past it seems to have been necessary to use proxy_media and disable bypass manually, so I had done that, not knowing this is deprecated.
So, if anybody of you FreeSWITCH wizards has ANY idea on how to get my setup working, I'd be very very *very* happy....
I love FreeSWITCH for it's clean and organized structure, it's flexibility and speed.... but t.38 drives me crazy... and that's of course NOT FreeSWITCH's fault!
Thanks to everybody who has time and willing to read my debugging stuff!
And of course sorry to Anthony, if I by any means disrespected you with my bad english! ;)
Greetings, John _______________________________________________ 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
_______________________________________________ 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, On 01.03.2011, at 18:30, Anthony Minessale wrote:
You need to get traces from the FreeSWITCH console more than a pcap.
Et voila: http://pastebin.freeswitch.org/15509 Same situation, same result, like in the other debug stuff. If you need anything else.... let me know. Thanks, John
Execute these commands on the cli: (don't forget any I often have to tell people to take traces more than once)
sofia global siptrace on console loglevel debug
Reproduce the problem situation then paste that log. Every new time something changes, repeat this step.
On Tue, Mar 1, 2011 at 11:18 AM, Madovsky <infos@madovsky.org> wrote:
since the implementation of T38 you should set proxy_media to false and bypass_media to false also....
----- Original Message ----- From: "Johannes Jakob" <jjj@3js.de> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, March 01, 2011 12:09 PM Subject: Re: [Freeswitch-users] T.38 Issues with passthrough handshaking
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
hehe, thank you, but I'm fully aware of who Anthony is and I *do* in fact fully trust him in all things FreeSWITCH ;) sorry if my badly chosen words imply I wouldn't!
All I wanted to say is, that the setup I had done and described in my first posting has been done after reading Anthony's, Michael's and Darren's book and lots and lots of wiki pages and mailing list postings. In the past it seems to have been necessary to use proxy_media and disable bypass manually, so I had done that, not knowing this is deprecated.
So, if anybody of you FreeSWITCH wizards has ANY idea on how to get my setup working, I'd be very very *very* happy....
I love FreeSWITCH for it's clean and organized structure, it's flexibility and speed.... but t.38 drives me crazy... and that's of course NOT FreeSWITCH's fault!
Thanks to everybody who has time and willing to read my debugging stuff!
And of course sorry to Anthony, if I by any means disrespected you with my bad english! ;)
Greetings, John _______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
On 01.03.2011, at 18:18, Madovsky wrote:
since the implementation of T38 you should set proxy_media to false and bypass_media to false also....
Okay, didn't know that, but do since Anthony told me. But as I said, I removed all of the proxy stuff from my xml config, but T.38 passthru still doesn't work the way I believe it has to ;)
----- Original Message ----- From: "Johannes Jakob" <jjj@3js.de> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, March 01, 2011 12:09 PM Subject: Re: [Freeswitch-users] T.38 Issues with passthrough handshaking
Okay, thanks for this hint, the wiki suggests proxy_media... Johannes, Anthony is one of the main developer of FS, so you can trust him at 100%
hehe, thank you, but I'm fully aware of who Anthony is and I *do* in fact fully trust him in all things FreeSWITCH ;) sorry if my badly chosen words imply I wouldn't!
All I wanted to say is, that the setup I had done and described in my first posting has been done after reading Anthony's, Michael's and Darren's book and lots and lots of wiki pages and mailing list postings. In the past it seems to have been necessary to use proxy_media and disable bypass manually, so I had done that, not knowing this is deprecated.
So, if anybody of you FreeSWITCH wizards has ANY idea on how to get my setup working, I'd be very very *very* happy....
I love FreeSWITCH for it's clean and organized structure, it's flexibility and speed.... but t.38 drives me crazy... and that's of course NOT FreeSWITCH's fault!
Thanks to everybody who has time and willing to read my debugging stuff!
And of course sorry to Anthony, if I by any means disrespected you with my bad english! ;)
Greetings, John _______________________________________________ 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
_______________________________________________ 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
participants (3)
-
Anthony Minessale
-
Johannes Jakob
-
Madovsky