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

[Joshua Colp]

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.

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