Joshua Colp
2017-Jun-11 11:29 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 08:16 AM, Michael Maier wrote: <snip>> I did some further investigations and fixed a local problem. Now, > asterisk is able to successfully activate T.38 - unfortunately just for > very shot time because of a phantom package it receives!What was the local problem?> Let's go into details: > I'm starting at the point where asterisk / fax client receives the T.38 > reininvite from the server from the provider 195.185.37.60:5060 for the > fax client (extension 91):<snip>> > But now, something strange happens: Asterisk "receives" a T.38 reinvite > package from provider! > Why is it strange? Because *this package doesn't exist at all* ! It > can't be seen in tcpdump. I did 4 tests - always the same! Where does > this package come from? It's exactly the same package which can be seen > at the beginning of the trace excerpted here! Isn't it been deleted > after it has been processed the first time?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. 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... -- 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-11 14:34 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 01:29 PM Joshua Colp wrote:> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote: > > <snip> > >> I did some further investigations and fixed a local problem. Now, >> asterisk is able to successfully activate T.38 - unfortunately just for >> very shot time because of a phantom package it receives! > > What was the local problem?Update of t38modem from 3.13 to 3.15>> Let's go into details: >> I'm starting at the point where asterisk / fax client receives the T.38 >> reininvite from the server from the provider 195.185.37.60:5060 for the >> fax client (extension 91): > > <snip> > >> >> But now, something strange happens: Asterisk "receives" a T.38 reinvite >> package from provider! >> Why is it strange? Because *this package doesn't exist at all* ! It >> can't be seen in tcpdump. I did 4 tests - always the same! Where does >> this package come from? It's exactly the same package which can be seen >> at the beginning of the trace excerpted here! Isn't it been deleted >> after it has been processed the first time? > > 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. Thanks, regards, Michael
Joshua Colp
2017-Jun-11 14:39 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 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
Michael Maier
2017-Jun-12 15:29 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 04:34 PM Michael Maier wrote:> On 06/11/2017 at 01:29 PM Joshua Colp wrote: >> On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote: >> >> <snip> >> >>> I did some further investigations and fixed a local problem. Now, >>> asterisk is able to successfully activate T.38 - unfortunately just for >>> very shot time because of a phantom package it receives! >> >> What was the local problem? > > Update of t38modem from 3.13 to 3.15I forgot to mention the main thing: I initially used *two* trunks (and one number), one "normal" trunk and another trunk_fax additionally enabling udptl. Outbound not a problem - but inbound used the normal trunk - this can't work. Merging both trunks to one trunk has been the solution, which isn't a problem with udptl, because it's initially handled by the extension (t38modem). That's why I came across line option for the other provider I'm using and which wasn't that easy to use with FreePBX, because it is not yet directly supported and pjsip.registration_custom_post.conf unfortunately doesn't work (I'm not the only one experiencing this problem). Therefore I'm using now a trick which works especially for the registration problem within FreePBX as long as it isn't supported natively. Thanks, Michael
Apparently Analagous 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'