asterisk users - Jun 2017 - 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 - PJSIP maintains no queue, a message comes in from
> a transport and is given to modules until one says it has handled the
> message. We place our distributor close to the transport and it puts the
> message into a queue for handling in Asterisk ensuring serialization as
> appropriate, returning that it has handled the message so no other
> modules handle it at that time. Once the message is handled from the
> queue it picks back up invoking modules at the point where the original
> thread left off. This ensures messages are handled as quickly as
> possible without blocking the transport but also provides guarantees on
> ordering and simultaneous execution. (Two messages for the same call
> will be handled in order, one at a time).
> 
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
+++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.233000000 +0200
@@ -407,6 +407,7 @@
                /* We have a BYE or CANCEL request without a serializer. */
                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_TRUE 3 - ready\n");
        ast_taskprocessor_unreference(serializer);
-
        return PJ_TRUE;
 }
 


Unfortunately, this patch crashes asterisk when debug is enabled. Is
there another way to check, if all the packages are really freed?


Thanks,
Michael

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
> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.233000000
> +0200
> @@ -407,6 +407,7 @@
>                 /* We have a BYE or CANCEL request without a serializer.
>                 */
>                 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_TRUE 3 - ready\n");
>         ast_taskprocessor_unreference(serializer);
> -
>         return PJ_TRUE;
>  }
>  
> 
> 
> Unfortunately, this patch crashes asterisk when debug is enabled. Is
> there another way to check, if all the packages are really freed?
That shouldn't cause Asterisk to crash. There's nothing built in to
specifically try to debug this kind of situation. Adding logging to try
to understand what is going on is probably the easiest way.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

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
>> +++ a/res/res_pjsip/pjsip_distributor.c 2017-06-13 20:25:27.233000000
>> +0200
>> @@ -407,6 +407,7 @@
>>                 /* We have a BYE or CANCEL request without a
serializer.
>>                 */
>>                
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_TRUE 3 - ready\n");
>>         ast_taskprocessor_unreference(serializer);
>> -
>>         return PJ_TRUE;
>>  }
>>  
>>
>>
>> Unfortunately, this patch crashes asterisk when debug is enabled. Is
>> there another way to check, if all the packages are really freed?
> 
> That shouldn't cause Asterisk to crash. There's nothing built in to
> specifically try to debug this kind of situation. Adding logging to try
> to understand what is going on is probably the easiest way.
> 
Got it - I had to change the complete asterisk-packages (I'm compiling
on base of spec file) - and not just the asterisk-core.

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 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
rdata0x7f9654081e18. I think, that's the problem. But I don't know what
it means and where it comes from. Do you have an idea?


Thanks,
Michael