[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'

[Michael Maier]

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?



Thanks,
Michael