Joshua Colp
2017-Jun-11 16:47 UTC
[asterisk-users] 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 the queue. > >> > >> That's the *expected* behavior ... . I rechecked again and again. All > >> existing tcpdumps. The "resent" package isn't part of any tcpdump > >> (wireshark doesn't show it) - and during tcpdump no package was dropped. > >> > >>> The > >>> only reason I'd expect to see it again is if there was a retransmission > >>> or something somehow requeued it up - but I don't think we do that > >>> anywhere. Not quite sure why it would be happening... > >> > >> But even if this package would have really been sent (as retransmission) > >> - shouldn't there be another response? T.38 has been successfully > >> enabled before and the faxclient has already sent a valid 200 ok > >> including complete SDP information to asterisk. > >> > >> All in all it looks really odd to me. > > > > Depends on how we handle that scenario. I don't think we have any tests > > to cover it, so it's entirely possible that we wouldn't respond like > > that. Why it's happening in the first place I still don't know though, > > haven't seen anything like it. > > Do you have any idea where to check if acted packages are really > removed? Is there a way 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 Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org
Joshua Colp
2017-Jun-11 16:51 UTC
[asterisk-users] 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: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: > > > > > > <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 any tcpdump > > >> (wireshark doesn't show it) - and during tcpdump no package was dropped. > > >> > > >>> The > > >>> only reason I'd expect to see it again is if there was a retransmission > > >>> or something somehow requeued it up - but I don't think we do that > > >>> anywhere. Not quite sure why it would be happening... > > >> > > >> But even if this package would have really been sent (as retransmission) > > >> - shouldn't there be another response? T.38 has been successfully > > >> enabled before and the faxclient has already sent a valid 200 ok > > >> including complete SDP information to asterisk. > > >> > > >> All in all it looks really odd to me. > > > > > > Depends on how we handle that scenario. I don't think we have any tests > > > to cover it, so it's entirely possible that we wouldn't respond like > > > that. Why it's happening in the first place I still don't know though, > > > haven't seen anything like it. > > > > Do you have any idea where to check if acted packages are really > > removed? Is there a way 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.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). -- 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
Michael Maier
2017-Jun-14 15:47 UTC
[asterisk-users] 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
Reasonably Related Threads
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'
- asterisk 13.16 / pjsip / t.38: res_pjsip_t38.c:207 t38_automatic_reject: Automatically rejecting T.38 request on channel 'PJSIP/91-00000007'