Displaying 20 results from an estimated 700 matches similar to: "asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'"
2017 Jun 05
3
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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)
2017 Jun 04
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 05
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 05
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 16
3
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 16
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 05
3
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 11
3
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 14
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
>> +++
2017 Jun 15
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 14
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 11
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2017 Jun 11
2
asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
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
2016 Jul 01
2
CALLERID on pjsip doesn't work?
Asterisk 13.8
Is CALLERID(all) supposed to wok for pjsip? When I do this:
exten => 1234,Set(CALLERID(all)="Jon Doe" <+123456789>)
same => n,Dial(PJSIP/phone123, 30)
I expect the callerid to be as set, but is always seems to be "phone123",
the name of the endpoint.
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2015 Jul 27
2
PJSIP T.38 issues
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
2 weks ago I asked questions about PJSIP and T.38 but got no replies. I
upgraded Asterisk to git as of yesterday (309dd2a), and I'm still having
the same issues.
In the trace below, I'm sending a fax from Hylafax server through
iaxmodem on Asterisk-13 (tiare) to a second Asterisk (11.18.0 t0gw)
connected to the PSTN via ISDN; the
2004 Sep 28
2
Asterisk, Hylafax and T38Modem - help!
Hi All,
I know that this may not strictly be an asterisk issue, but if anyone has
any ideas on this prob it would be appreciated.
I have a working asterisk setup using Suse 9.1, a BT ISDN BRI card
(Fritz?), sipura 3000 and a few cisco 7940's. I wanted to do add faxing
into the equation, so I thought I would try and setup the following:
PSTN->asterisk->hylafax->pc
At the moment
2012 Oct 08
1
Asterisk, Hylafax and t38modem working together ?
Hi,
I've read this thread in this list history
http://article.gmane.org/gmane.comp.telephony.pbx.asterisk.user/261151/match=t38modem
http://sourceforge.net/tracker/?func=detail&aid=3337581&group_id=152230&atid=783657
Has anyone been successful when integrating latest version of Asterisk (10
or 1.8, for instance) with t38modem ?
My target setup is:
fax ---<PSTN>-- SPA3102
2007 Jul 06
2
Legacy PTY Support ?
I am looking at T38Modem. A relatively new version is ready for someone
to build an rpm for (Mar '07).
But the readme warns:
Q. I try to use T38modem, but after run "t38modem -p ttyx0" I get a message
"Could not open /dev/ptyx0: No such file or directory".
A. Looks like you don't have legacy PTY devices compiled in your kernel.
You need to re-compile the
2013 May 07
2
Asterisk and hylafax: how to debug ...
Hi,
I hope you might give me some hints on how to find where my
configuration is wrong, I am new to Asterisk and do not know, how to
find the problem.
Running Asterisk (version: 1.8.13.1~dfsg-3) on Debian Wheezy. On the
same maschine: Hylafax fax server. I want hylafax to use t38modem (a
virtual T.38 modem) for sending faxes. t38modem schould connect to
asterisk on the same host.
If hylafax
2010 Jun 24
2
T.38 on a MAX/Lucent/Ascend TNT
Hello folks,
I've been trying to get T.38 over SIP working with calls terminated by a
MAX/Lucent/Ascent TNT. As far as I can tell, SIP and T.38 are actually
working perfectly; however, I can't get the TNT to properly terminate a
FAX call. Does anyone have a working configuration for SIP and T.38 for
calls from a TNT or APX?
Here's a brief description/diagram of my test setup: