[Freeswitch-users] T.38 Issues with passthrough handshaking
Madovsky
infos at madovsky.org
Tue Mar 1 19:40:00 MSK 2011
> > 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 at 3js.de>
To: "FreeSWITCH Users Help" <freeswitch-users at 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;
>
> 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 at 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 at 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:
>>>
>>> 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 at sbc1.mysip.net, with session
>>>> description
>>>> AkE`b?FG^^B%INVITE sip:017286483798 at sbc1.mysip.net SIP/2.0
>>>> Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec
>>>> Max-Forwards: 70
>>>> From: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
>>>> To: <sip:017286483798 at sbc1.mysip.net>
>>>> Contact: <sip:0692386432 at 10.16.139.28:5060>
>>>> Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
>>>> CSeq: 103 INVITE
>>>> User-Agent: FPBX-2.8.1(1.8.2.4)
>>>> Proxy-Authorization: Digest username="sipuser", realm="mysip.net",
>>>> algorithm=MD5, uri="sip:017286483798 at sbc1.mysip.net",
>>>> nonce="aa9339fc-9e53-4017-85ff-fac5367cb733",
>>>> response="96f4dea7267d436779cd106947cc25b7", qop=auth,
>>>> cnonce="4e110d27", nc=00000001
>>>> Date: Thu, 24 Feb 2011 07:30:27 GMT
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>> INFO, PUBLISH
>>>> Supported: replaces, timer
>>>> Content-Type: application/sdp
>>>> Content-Length: 285
>>>>
>>>> v=0
>>>> o=root 1297612317 1297612318 IN IP4 10.16.139.28
>>>> s=Asterisk PBX 1.8.2.4
>>>> c=IN IP4 10.16.139.28
>>>> t=0 0
>>>> m=audio 15000 RTP/AVP 0 8 3 101
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:3 GSM/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fmtp:101 0-16
>>>> a=ptime:20
>>>> a=sendrecv
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> SBC is forwarding the request to the correct gateway:
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 11 37.716704 10.16.133.66 10.15.12.215 SIP/SDP 1232
>>>> Request: INVITE sip:+4317286483798 at 10.15.12.215, with session
>>>> description
>>>> =|$E%@^BWB{INVITE sip:+4317286483798 at 10.15.12.215 SIP/2.0
>>>> Via: SIP/2.0/UDP 10.16.133.66:5080;rport;branch=z9hG4bK33eQ6Na9D991D
>>>> Max-Forwards: 69
>>>> From: "0692386432" <sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
>>>> To: <sip:+4317286483798 at 10.15.12.215>
>>>> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
>>>> CSeq: 8930272 INVITE
>>>> Contact: <sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1>
>>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19
>>>> 23-38-04 +0100
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>>> REGISTER, REFER, NOTIFY
>>>> Supported: timer, precondition, path, replaces
>>>> Allow-Events: talk, hold, refer
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 269
>>>> X-FS-Support: update_display
>>>> Remote-Party-ID: "0692386432"
>>>> <sip:0692386432 at 10.16.133.66>;party=calling;screen=yes;privacy=off
>>>> P-Asserted-Identity: <sip:06923864320 at sip.gateway.de>
>>>>
>>>> v=0
>>>> o=FreeSWITCH 3022782041 3022782042 IN IP4 10.16.133.66
>>>> s=FreeSWITCH
>>>> c=IN IP4 10.16.133.66
>>>> t=0 0
>>>> m=audio 18446 RTP/AVP 0 8 3 101
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:3 GSM/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fmtp:101 0-16
>>>> a=ptime:20
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> Gatway says, everything OK, audio call patched through:
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 22 39.760159 10.15.12.215 10.16.133.66 SIP/SDP 750
>>>> Status: 200 OK, with session description
>>>> AkEw W^BSIP/2.0 200 OK
>>>> Via: SIP/2.0/UDP
>>>> 10.16.133.66:5080;branch=z9hG4bK33eQ6Na9D991D;rport=5080
>>>> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
>>>> From: "0692386432"<sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
>>>> To: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
>>>> CSeq: 8930272 INVITE
>>>> Allow:
>>>> INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
>>>> Contact: <sip:10.15.12.215:5060;user=phone>
>>>> Content-Length: 217
>>>> Content-Type: application/sdp
>>>>
>>>> v=0
>>>> o=HuaweiSoftX3000 3014926 3014927 IN IP4 10.15.12.215
>>>> s=Sip Call
>>>> c=IN IP4 10.15.12.215
>>>> t=0 0
>>>> m=audio 15490 RTP/AVP 0 101
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=ptime:20
>>>> a=fmtp:101 0-15
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> SBC is telling the asterisk box, everything is fine
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 28 39.770349 10.16.133.66 10.16.139.28 SIP/SDP 1185
>>>> Status: 200 OK, with session description
>>>> =|$Ew at 1y^B^}aSIP/2.0 200 OK
>>>> Via: SIP/2.0/UDP 10.16.139.28:5060;branch=z9hG4bK3c5810ec
>>>> From: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
>>>> To: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
>>>> Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
>>>> CSeq: 103 INVITE
>>>> Contact: <sip:017286483798 at 10.16.133.66:5060;transport=udp>
>>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19
>>>> 23-38-04 +0100
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>>> Supported: timer, precondition, path, replaces
>>>> Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla,
>>>> include-session-description, presence.winfo, message-summary, refer
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 222
>>>> Remote-Party-ID: "017286483798"
>>>> <sip:017286483798 at 10.16.133.66>;party=calling;privacy=off;screen=no
>>>>
>>>> v=0
>>>> o=FreeSWITCH 3022845683 3022845684 IN IP4 10.16.133.66
>>>> s=FreeSWITCH
>>>> c=IN IP4 10.16.133.66
>>>> t=0 0
>>>> m=audio 28850 RTP/AVP 0 101
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fmtp:101 0-15
>>>> a=ptime:20
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> so, after the ACK which is passed along as well, there is the typical
>>>> audio stuff, ringing... in both directions the right, pre-negotiated
>>>> udp ports, everything is fine so far:
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 45 39.849484 10.15.12.215 10.16.133.66 RTP 216
>>>> PT=ITU-T G.711 PCMU, SSRC=0x727E59A0, Seq=23045, Time=3032460352
>>>> User Datagram Protocol, Src Port: 15490 (15490), Dst Port: 18446
>>>> (18446)
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 46 39.849541 10.16.133.66 10.16.139.28 RTP 216
>>>> PT=ITU-T G.711 PCMU, SSRC=0x727E59A0, Seq=23045, Time=3032460352
>>>> User Datagram Protocol, Src Port: 28850 (28850), Dst Port: hydap
>>>> (15000)
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> Now, the magic happens, the gateway is sending it's T.38 re-INVITE to
>>>> establish better fax connectivity... well, let's see what happens:
>>>>
>>>> The gateway is suggesting to move the audio stuff from port 15490 to
>>>> 15492, and instead speak t38/udptl on port 15490, keep that in mind.
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2099 50.121304 10.15.12.215 10.16.133.66 SIP/SDP 1026
>>>> Request: INVITE
>>>> sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1, in-dialog,
>>>> with session description
>>>> AkEW^BwINVITE
>>>> sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1 SIP/2.0
>>>> Via: SIP/2.0/UDP
>>>> 10.15.12.215:5060;branch=z9hG4bK4abf7e790396e9d932f59632f
>>>> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
>>>> From: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
>>>> To: "0692386432"<sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
>>>> CSeq: 2 INVITE
>>>> Max-Forwards: 69
>>>> Contact: <sip:10.15.12.215:5060>
>>>> Content-Length: 527
>>>> Content-Type: application/sdp
>>>>
>>>> v=0
>>>> o=HuaweiSoftX3000 3014926 3014928 IN IP4 10.15.12.215
>>>> s=Sip Call
>>>> c=IN IP4 10.15.12.215
>>>> t=0 0
>>>> m=image 15490 udptl t38
>>>> a=T38FaxVersion:0
>>>> a=T38MaxBitRate:14400
>>>> a=T38FaxRateManagement:transferredTCF
>>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>> m=audio 15492 RTP/AVP 8 0 127 103 101
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:127 PCMU/8000
>>>> a=gpmd:127 vbd=yes
>>>> a=rtpmap:103 PCMA/8000
>>>> a=gpmd:103 vbd=yes
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=ptime:20
>>>> a=silenceSupp:off - - - -
>>>> a=ecan:fb on -
>>>> a=X-fax
>>>> a=fmtp:101 0-15
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> FS is handing this INVITE to asterisk (and tells asterisk, it would
>>>> accept audio and/or t.38, both on the same port 28850, don't think
>>>> that's a problem, but it's at least different from HuaweiSoftX3000's
>>>> behavior):
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2101 50.122833 10.16.133.66 10.16.139.28 SIP/SDP 1398
>>>> Request: INVITE sip:0692386432 at 10.16.139.28:5060, in-dialog, with
>>>> session description
>>>> =|$Efw at 0^B^R6INVITE sip:0692386432 at 10.16.139.28:5060 SIP/2.0
>>>> Via: SIP/2.0/UDP 10.16.133.66;rport;branch=z9hG4bKy5perv1F90acS
>>>> Max-Forwards: 70
>>>> From: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
>>>> To: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
>>>> Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
>>>> CSeq: 8930278 INVITE
>>>> Contact: <sip:017286483798 at 10.16.133.66:5060;transport=udp>
>>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19
>>>> 23-38-04 +0100
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>>> REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>>>> Supported: timer, precondition, path, replaces
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 532
>>>> X-FS-Support: update_display
>>>> P-Asserted-Identity: <sip:06923864320 at sip.gateway.de>
>>>>
>>>> v=0
>>>> o=FreeSWITCH 3022845683 3022845685 IN IP4 10.16.133.66
>>>> s=FreeSWITCH
>>>> c=IN IP4 10.16.133.66
>>>> t=0 0
>>>> m=image 28850 udptl t38
>>>> a=T38FaxVersion:0
>>>> a=T38MaxBitRate:14400
>>>> a=T38FaxRateManagement:transferredTCF
>>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>> m=audio 28850 RTP/AVP 8 0 127 103 101
>>>> a=rtpmap:8 PCMA/8000
>>>> a=rtpmap:0 PCMU/8000
>>>> a=rtpmap:127 PCMU/8000
>>>> a=rtpmap:103 PCMA/8000
>>>> a=rtpmap:101 telephone-event/8000
>>>> a=fmtp:101 0-15
>>>> a=gpmd:127 vbd=yes
>>>> a=gpmd:103 vbd=yes
>>>> a=ptime:20
>>>> a=silenceSupp:off - - - -
>>>> a=ecan:fb on -
>>>> a=X-fax
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> The asterisk box says this is fine (after of course successfully
>>>> talking to the ATA, which is fine with it, too, but want's to have
>>>> slower speed). The asterisk box is also changing the port it wants to
>>>> get t38 data on from 15508 to 4676 and finally sets the udp port for
>>>> audio 0 to disable it.
>>>> Just plain t.38 in the new SDP description:
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2107 50.165366 10.16.139.28 10.16.133.66 SIP/SDP 920
>>>> Status: 200 OK, with session description
>>>> AkE`b?G^^^BtAbSIP/2.0 200 OK
>>>> Via: SIP/2.0/UDP
>>>> 10.16.133.66;branch=z9hG4bKy5perv1F90acS;received=10.16.133.66;rport=5060
>>>> From: <sip:017286483798 at sbc1.mysip.net>;tag=crS25Ur70m0BK
>>>> To: "0692386432" <sip:0692386432 at mysip.net>;tag=as235c17b6
>>>> Call-ID: 6de3237b20a96ab010fb9b3f2436d305 at mysip.net
>>>> CSeq: 8930278 INVITE
>>>> Server: FPBX-2.8.1(1.8.2.4)
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>>> INFO, PUBLISH
>>>> Supported: replaces, timer
>>>> Contact: <sip:0692386432 at 10.16.139.28:5060>
>>>> Content-Type: application/sdp
>>>> Content-Length: 307
>>>>
>>>> v=0
>>>> o=root 1297612317 1297612319 IN IP4 10.16.139.28
>>>> s=Asterisk PBX 1.8.2.4
>>>> c=IN IP4 10.16.139.28
>>>> t=0 0
>>>> m=audio 0 RTP/AVP 8 0 127 103 101
>>>> m=image 4676 udptl t38
>>>> a=T38FaxVersion:0
>>>> a=T38MaxBitRate:9600
>>>> a=T38FaxRateManagement:transferredTCF
>>>> a=T38FaxMaxDatagram:397
>>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> BUT look at this! What does FreeSWITCH tell the gateway???
>>>> It sends 200 OK, but suddenly wants to receive only audio data and
>>>> disables comfort noise?
>>>> Same udp port as before, but no sign of t.38 in the SDP description!
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2111 50.170760 10.16.133.66 10.15.12.215 SIP/SDP 902
>>>> Status: 200 OK, with session description
>>>> =|$Ev%@^BWbA1SIP/2.0 200 OK
>>>> Via: SIP/2.0/UDP
>>>> 10.15.12.215:5060;branch=z9hG4bK4abf7e790396e9d932f59632f
>>>> From: <sip:+4317286483798 at 10.15.12.215>;tag=h1hl6tsu-CC-39
>>>> To: "0692386432" <sip:0692386432 at 10.16.133.66>;tag=4NH77aQN2v7ZS
>>>> Call-ID: e5c9ab65-ba8a-122e-21ad-863d7c249180
>>>> CSeq: 2 INVITE
>>>> Contact: <sip:gw+gateway1 at 10.16.133.66:5080;transport=udp;gw=gateway1>
>>>> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-7847289 2011-02-19
>>>> 23-38-04 +0100
>>>> Accept: application/sdp
>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
>>>> REGISTER, REFER, NOTIFY
>>>> Supported: timer, precondition, path, replaces
>>>> Content-Type: application/sdp
>>>> Content-Disposition: session
>>>> Content-Length: 168
>>>>
>>>> v=0
>>>> o=FreeSWITCH 3022782041 3022782043 IN IP4 10.16.133.66
>>>> s=FreeSWITCH
>>>> c=IN IP4 10.16.133.66
>>>> t=0 0
>>>> m=audio 18446 RTP/AVP 8 0 127 103 101
>>>> m=audio 0 RTP/AVP 19
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> and look at this, even though we just told the gateway to only talk
>>>> audio to it, we send a t38 packet! (it's this lonely one though!)
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2112 50.174592 94.186.133.66 87.234.1.215 T.38 216
>>>> UDP: UDPTLPacket Seq=32768 t30ind: <unknown>[UNKNOWN PER:
>>>> 10.9.3.8.1][Malformed Packet]
>>>> User Datagram Protocol, Src Port: 18446 (18446), Dst Port: 15490
>>>> (15490)
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> The gateway keeps sending normal audio to us on the specified and
>>>> unchanged port, BUT from the udp port it originally told us it would
>>>> only accept t.38 on...
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2260 51.589980 10.15.12.215 10.16.133.66 RTP 216
>>>> PT=ITU-T G.711 PCMA, SSRC=0x727E59A0, Seq=23634, Time=3032554272
>>>> User Datagram Protocol, Src Port: 15490 (15490), Dst Port: 18446
>>>> (18446)
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>> While the gateway is sending us plain audio, we are talking t38 to the
>>>> asterisk box (which is not responding).
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>> 2261 51.590063 10.16.133.66 10.16.139.28 T.38 216
>>>> UDP: UDPTLPacket Seq=32776 data:v8:[UNKNOWN PER: too long
>>>> integer(per_integer)][Malformed Packet]
>>>> User Datagram Protocol, Src Port: 28850 (28850), Dst Port: dhct-alerts
>>>> (4676)
>>>> -----------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> For the record, on the asterisk (version 1.8.2.4) box I defined
>>>> t38pt_udptl=yes,redundancy
>>>> directmedia=no
>>>> for the gateways and the ATA's extension.
>>>>
>>>> On both, the sbc and the asterisk box I compiled res_fax_spandsp,
>>>> mod_spandsp with spandsp-0.0.6pre18.
>>>>
>>>> So... I've been spending far tooooo much time debugging this and I'm
>>>> quite sure I'm just too stupid to find a solution for this.
>>>>
>>>>
>>>> Is there any good pcap anonymizing utitlity, that can substitute
>>>> application layer stuff as well?
>>>>
>>>> Well, *any* help/hint would be appreciated very much ;)
>>>>
>>>> Thanks in advance,
>>>>
>>>> John
>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at 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 at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
More information about the FreeSWITCH-users
mailing list