Displaying 5 results from an estimated 5 matches for "pj_true".
Did you mean:
js_true
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 distributor itself, though,
>> ends up executing things further in a worker thread using the distribute
>> function.
>
> To be more detailed - PJSI...
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'
...to check the pjsip-queue? Where could I start to
> look at? How does asterisk get them from the queue? And how does pjsip
> know that asterisk has processed them?
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 distributor itself, though,
ends up executing things further in a worker thread using the distribute
function.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis D...
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'
...*/
>> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
>> rdata,
>> PJSIP_SC_CALL_TSX_DOES_NOT_EXIST, NULL, NULL,
>> NULL);
>> + ast_debug(3, "PJ_TRUE 1\n");
>> return PJ_TRUE;
>> } else {
>> if (ast_taskprocessor_alert_get()) {
>> @@ -439,8 +440,8 @@
>> pjsip_rx_data_free_cloned(clone);
>> }
>>
>> + ast_debug(3, "PJ_T...
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'
...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 output:
>>
>> ast_debug(3, "PJ_TRUE 3 - ready %s\n", pjsip_rx_data_get_info(rdata));
>>
>> This gives, that for *all* received packages return PJ_TRUE is reached.
>>
>> But: all packages besides of the phantom resend use the same address
>> rdata0x7f963c0009b8 - only the phantom resent package uses...
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