search for: t38_automatic_reject

...-> extension -> trunk -> ISP -> trunk -> extension -> t39modem(2) -> hylafax Same procedure: the receiving t38modem(2) sends ReInvite for t.38 - but this time, the extension / asterisk just ignores it. After the 5. retry to switch to T.38, asterisk tells: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007' => Why does asterisk reject the switch / ReInvite to T.38 this time? It never even tried to send it to the ISP! Thanks for any hint! Regards, Michael

On Fri, Jun 16, 2017, at 02:13 AM, Michael Maier wrote: > Has anybody any idea why asterisk drops the media stream in the 200 OK? > The channel has been T38_ENABLED before! Or is it necessary to add more > debug code? Who does the negotiating? > Only asterisk or is pjsip doing some parts, too? Asterisk does the T.38 negotiation and produces the answer SDP, PJSIP does the SDP

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 are happening as they happen here. The logic for T.38 negotiation lives all in the res_pjsip_t38 module and the request to negotiate works using a

On 06/04/2017 at 01:41 PM Telium Technical Support wrote: > Just a guess (without knowing about your network), but are the two ends > points on public networks and visible to one another? If not the reinvite > may be passing an internal (nat'ed) address to the other and the connection > will fail...just a though t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen

On 06/11/2017 at 06:51 PM Joshua Colp wrote: > On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote: >> The distributor is in res/res_pjsip/pjsip_distributor.c, the distributor >> function being the entry point. That function returning PJ_TRUE >> indicates to PJSIP that it has been handled and no subsequent modules >> should be called by that running thread. The

On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote: <snip> > > > > PJSIP uses a dispatch model. The request is queued up, acted on, and > > then that's it. The act of acting on it removes it from the queue. > > That's the *expected* behavior ... . I rechecked again and again. All > existing tcpdumps. The "resent" package isn't part of

On Mon, Jun 5, 2017, at 12:00 PM, Joshua Colp wrote: > On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote: > > On 06/05/2017 at 11:30 AM, Joshua Colp wrote: > > > On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote: > > >> On 06/04/2017 at 01:41 PM Telium Technical Support wrote: > > >>> Just a guess (without knowing about your network), but are

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

On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote: <snip> > I did some further investigations and fixed a local problem. Now, > asterisk is able to successfully activate T.38 - unfortunately just for > very shot time because of a phantom package it receives! What was the local problem? > Let's go into details: > I'm starting at the point where asterisk / fax

On Sun, Jun 11, 2017, at 01:31 PM, Michael Maier wrote: > On 06/11/2017 at 04:39 PM Joshua Colp wrote: > > On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote: > > > > <snip> > > > >>> > >>> PJSIP uses a dispatch model. The request is queued up, acted on, and > >>> then that's it. The act of acting on it removes it from

On 06/05/2017 at 11:30 AM, Joshua Colp wrote: > On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote: >> On 06/04/2017 at 01:41 PM Telium Technical Support wrote: >>> Just a guess (without knowing about your network), but are the two ends >>> points on public networks and visible to one another? If not the reinvite >>> may be passing an internal (nat'ed)

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

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 >> +++

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