On 06/17/2017 at 02:18 PM, Michael Maier wrote:
> On 06/16/2017 at 04:00 PM, Joshua Colp wrote:
>> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
>>
>>
>>
>>>
>>> t38modem and asterisk are using
>>>
>>> m=image 35622 udptl t38
>>>^
>>>
>>> Provider uses
>>>
>>>
On Sat, Jun 17, 2017, at 09:18 AM, Michael Maier wrote:
>
> I can proof, that UDPTL vs. udptl is the problem. After "fixing"
> asterisk and opal both using UDPTL, the negotiation works flawlessly.
> See attached patches.
>
> Sending t38 faxes internally works fine. Externally via provider
On 06/16/2017 at 04:00 PM, Joshua Colp wrote:
> On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
>
>
>
>>
>> t38modem and asterisk are using
>>
>> m=image 35622 udptl t38
>>^
>>
>> Provider uses
>>
>> m=image 35622 UDPTL t38
>>^
>>
>> Could this be
On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote:
>
> 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
>
Am 16.06.2017 um 11:12 schrieb Joshua Colp:
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
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?
On 06/15/2017 at 08:15 AM Michael Maier wrote:
> On 06/14/2017 at 10:17 PM, Joshua Colp wrote:
>> On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote:
>>
>>
>>
>>>
>>> I can now say, that asterisk / pjsip seams to work *mostly* as expected.
>>> Just one exception - and that's the package in
On 06/14/2017 at 10:17 PM, Joshua Colp wrote:
> On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote:
>
>
>
>>
>> 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
On Wed, Jun 14, 2017, at 05:09 PM, Michael Maier wrote:
>
> 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 the info at the last
On 06/14/2017 at 05:53 PM Joshua Colp wrote:
> On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote:
>
>
>
>>
>> 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.0
>>
On Wed, Jun 14, 2017, at 12:47 PM, Michael Maier wrote:
>
> 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.0
> +0200
> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13
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
On 06/11/2017 at 11:35 PM Daniel Tryba wrote:
> On Sun, Jun 11, 2017 at 01:16:10PM +0200, Michael Maier wrote:
>> Let's go into details:
>> I'm starting at the point where asterisk / fax client receives the T.38
>> reininvite from the server from the provider 195.185.37.60:5060 for the
>> fax
On 06/11/2017 at 04:34 PM Michael Maier wrote:
> On 06/11/2017 at 01:29 PM Joshua Colp wrote:
>> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote:
>>
>>
>>
>>> I did some further investigations and fixed a local problem. Now,
>>> asterisk is able to successfully activate T.38 -
On Sun, Jun 11, 2017 at 01:16:10PM +0200, Michael Maier wrote:
> Let's go into details:
> I'm starting at the point where asterisk / fax client receives the T.38
> reininvite from the server from the provider 195.185.37.60:5060 for the
> fax client (extension 91):
I'm running Asterisk 11 on my
On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote:
> 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:
> > >
> > >
> > >
> > >>>
> > >>> PJSIP uses a dispatch model. The
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:
> >
> >
> >
> >>>
> >>> PJSIP uses a dispatch model. The request is queued up, acted on, and
> >>> then that's it. The act of acting
On 06/11/2017 at 04:39 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote:
>
>
>
>>>
>>> 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
On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote:
> >
> > 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
On 06/11/2017 at 01:29 PM Joshua Colp wrote:
> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote:
>
>
>
>> 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
On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote:
> 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?
>
On 06/05/2017 at 09:32 PM Joshua Colp wrote:
> 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
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
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 are
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
On 06/05/2017 at 06:10 PM, Joshua Colp wrote:
> 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
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
On 06/05/2017 at 05: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
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 the two
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?
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
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
ip_t38.c:207
t38_automatic_reject: Automatically rejecting T.38 request on channel
'PJSIP/91-0007'
Hello!
I'm still trying to get a working t.38 configuration w/ pjsip.
I'm now able to send t.38 faxes to my own extension:
hylafax -> t38modem -> extension -> extension -> t
Hello!
I'm still trying to get a working t.38 configuration w/ pjsip.
I'm now able to send t.38 faxes to my own extension:
hylafax -> t38modem -> extension -> extension -> t38modem -> hylafax.
The fax is sent by t38modem. The receiving part of t38modem accepts the
call, sends ReInvite for
34 matches
Mail list logo
