similar to: Fax buffer overflow detected

What I have is: * Asterisk 1.8.10.1~dfsg-1ubuntu1, * SPA112 ATA with analog fax in 1-st FXS port connected, * SIP trunk with provider supporting T.38. My network looks like this: * spa112 (192.168.33.200/24) and Asterisk (192.168.5.253/24) in neighbouring LANs, * Asterisk connects to the provider (80.75.130.136) via router (82.200.7.184). Router has full DNAT to Asterisk server. What happens?

Hello, We're trying to receive faxes on the Asterisk server, but for the time being T.38 negotiation fails. The SDP that the Asterisk reINVITE sends contains these lines: ---------------------- m=image 4968 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxFillBitRemoval a=T38FaxTranscodingMMR a=T38FaxTranscodingJBIG a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:1400

Hi, I configured Asterisk 10 for inbound fax, for couple of weeks I didn't see any issues until today. The setup I configured for inbound fax is quite simple i.e. Cisco Voice GW sends the fax calls to Asterisk using T.38 protocol and later Asterisk stores/forwards the fax to specific end user. The configuration I made in sip.conf for enabling T38 is listed below; t38pt_udptl =

On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote: <snip> > > t38modem and asterisk are using > > m=image 35622 udptl t38 > ^^^^^ > > Provider uses > > m=image 35622 UDPTL t38 > ^^^^^ > > Could this be a problem? If I'm sending internal only, it's always > lowercase. Looking at the tests we have we

Hello, I have a problem with movistar in Mexico with a sip calls. Movistar send to me T38 and G729 in the INVITE and they say that I have to ignore T38 and use G729 in the voice call. When a fax call is made Movistar send only T38 in the INVITE. Invite example: v=0 o=GDL-BMSW-12D 19913379 19899826 IN IP4 192.168.1.2 s=sip call c=IN IP4 192.168.1.2 t=0 0 m=audio 6370 RTP/AVP 18 101 a=fmtp:18

Hi Guys, Something I have noticed while dealing with T.38 and re-invites in Asterisk 1.4.22. I have a provider who re-invites with the following sdp (message flow PROVIDER_EQPMT -> ASTERISK): """ . v=0. o=SIP_5F9 123456 654322 IN IP4 CONN_IP_PROVIDER. s=-. c=IN IP4 CONN_IP_PROVIDER. t=0 0. m=audio 0 RTP/AVP 0. m=image 26858 udptl t38. a=T38FaxMaxBuffer:288.

Hello, We are trying to send faxes by T.38 protocol to a remote SIP proxy from a local extension. The local extension sends the INVITE, Asterisk sends the call to the Proxy the call is connected with a regular audio codec. After a few seconds the remote proxy sends an INVITE with UDPTL and the Asterisk sends it to the local extension and it's accepted, but (here the problem starts) just

On Mon, Jun 5, 2017, at 04:26 PM, Michael Maier wrote: > On 06/05/2017 at 06:29 PM, Joshua Colp wrote: > > On Mon, Jun 5, 2017, at 01:22 PM, Michael Maier wrote: > >> > >> Do you have any idea where to start to look at? Adding additional output > >> in the source code? Which functions could be interesting? I may add own > >> debug code to see why things

All; I'm having a problem sending an outbound fax using Asterisk-1.8.15-cert3 and the spandsp fax module using a SIP trunk. I'm seeing hundreds of these: ERROR[14423]: udptl.c:294 encode_open_type: UDPTL (SIP/runcentral_outbound-00000074): Buffer overflow detected (59 + 134 > 175) Has anyone ever seen this before? I have the following configuration. udptl.conf:

On 06/14/2017 at 05:53 PM Joshua Colp wrote: > On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote: > > <snip> > >> >> I added this patch to see, if really all packages are are freed after >> they have been processed: >> >> --- b/res/res_pjsip/pjsip_distributor.c 2017-05-30 19:44:16.000000000 >> +0200 >> +++

Hi All, Excited to see mention of T.38 passthru with 1.4.0.... BUT it seems like "Emperor's New Clothes" from my perspective. As I understand it, T.38 passthru only works via a re-invite mechanism - so two T.38 devices try talking fax and request a T.38 media stream. Asterisk is now savvy enough to realise it can't do it, so opts out - "Hey Guys, I don't know

Hi All I have been looking around and haven not been able to find a working example I have a fresh/new install of Asterisk 1.6.2.0 with dahdi 2.2.1 and libpri 1.4.10.2 I use a sangoma A200 card so I am using wanpipe 3.4.7 If I use zaptel which I read I need for app_rxfax then asterisk crashes with segfaults on startup asterisk[2624]: segfault at 30353466 ip b7eb538b sp bffda26c error 4 in

Anyone have any testing experience with T38 and HT-502 Grandstream? I just want to confirm that t.38 is working on this device. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110801/fea18d8c/attachment.htm>

On 06/14/2017 at 10:17 PM, Joshua Colp wrote: > On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote: > > <snip> > >> >> I can now say, that asterisk / pjsip seams to work *mostly* as expected. >> Just one exception - and that's the package in question, which can't be >> seen in tcpdump. >> >> I extended the above patch by adding

Does anybody have T.38 faxing working with Flowroute? I am running Asterisk 1.6.2.7-rc3 with spandsp 0.0.6-pre17. I can successfully receive faxes over ulaw. I enabled T.38 with t38pt_udptl=yes in sip.conf. When I receive a fax it tries to negotiate T.38 and Flowroute sends back a Bad Request response saying I have a SIP syntax error. Flowroute support is recommending that I try again after

Hi, folks. I'm having a heck of a time trying to get outgoing T38 faxing (I don't need inbound right now) working with FFA and Gafachi. G711 faxing works (as well as can be expected over the internet), but I want the higher reliability of T38. I'm running Asterisk 10-beta1. When I drop my callfile in to make the call, I get this: -- Attempting call on SIP/18884732963 at

After upgrading from asterisk-10.5.0 to asterisk-11.1.2, I am getting a Segmentation fault. [root at localhost asterisk-11.1.2]# asterisk -vvvvvvc Asterisk 11.1.2, Copyright (C) 1999 - 2012 Digium, Inc. and others. Created by Mark Spencer <markster at digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components

Hello, at first, thanks for helping! In the meantime, I have done a lot of research and trial and error, and I could solve that specific problem. Obviously, the dialplan application "Answer" was playing a key role here. My original dialplan snippet (which produced that problem) was: exten => _00., 1, NoOp() same => n, Set(FAXOPT(gateway)=yes) same => n,