<div dir="ltr"><div>Hi Joshua,</div><div><br></div><div>Thanks very much for that information. I guess in that case the 'not working' scenario has a T38 state of 'T38 was negotiated and is active', which doesn't help us find the problem much. <br></div><div><br></div><div>In this case the T38 is passthrough, and in the not working scenario in a PCAP we see:</div><div>PSTN -> Asterisk: 't30ind: cng' packet is received</div><div>Asterisk -> ATA: 't30ind: cng' is not sent<br></div><div><br></div><div>Would you have any suggestion on what could prevent the 't30ind: cng' being passed through? The Asterisk T38 settings in sip.conf are:</div><div><br></div><div>t38pt_udptl = yes<br>t38_udptl = yes<br>t38pt_rtp = no<br>t38pt_tcp = no</div><div><br></div><div>Thanks again.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 18 Mar 2022 at 21:59, Joshua C. Colp <<a href="mailto:jcolp@sangoma.com" target="_blank">jcolp@sangoma.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Mar 18, 2022 at 12:27 AM David Cunningham <<a href="mailto:dcunningham@voisonics.com" target="_blank">dcunningham@voisonics.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>We have a problem where one fax ATA connected to Asterisk works, and another ATA with the same model and firmware does not. Both are configured to use T38. <br></div><div><br></div><div>Basically the call comes in to Asterisk which then does a Dial to the ATA that's registered via SIP, and once that's set up then there's a re-INVITE from the ATA to switch to T38. The ATA sends a "t30ind: no-signal" after the 200 OK, and both work up until this point. But then in the working scenario Asterisk sends a "t30ind: cng" back to the ATA, and in the not-working scenario Asterisk does not send any T38 data at all.</div><div><br></div><div>We've noticed that in the working scenario when the 200 OK is sent from Asterisk to the ATA, Asterisk logs:</div><div><br></div><div>[Mar 17 16:07:50] DEBUG[53838][C-0013e292] chan_sip.c: T38 state changed to 2 on channel SIP/xx.xx.246.70:5060-0030dde1<br>[Mar 17 16:07:50] DEBUG[6862][C-0013e292] chan_sip.c: T38 state changed to 1 on channel SIP/product-local-bw70-0030ddd9<br></div><div><br></div><div>Whereas in the not working scenario it logs:</div><div><br></div><div>[Mar 17 16:23:05] DEBUG[53838][C-0013e39a] chan_sip.c: T38 state changed to 3 on channel SIP/product-local-bw70-0030e0a0<br>[Mar 17 16:23:05] DEBUG[24973][C-0013e39a] chan_sip.c: T38 state changed to 3 on channel SIP/xx.xx.246.70:5060-0030e0a1<br></div><div><br></div><div>Notice the difference in the "T38 state changed to" values. Does anyone know what a value of 1, 2, or 3 means? I tried to find out from the Asterisk source code but it wasn't obvious.</div><div><br></div><div>Thank you in advance for any tips.<br></div></div></blockquote><div><br></div><div>The states you are referring to are chan_sip specific. They are defined here[1].</div><div><br></div><div>0 = Disabled</div><div>1 = We've sent a reinvite to switch to T.38</div><div>2 = They've sent a reinvite to switch to T38</div><div>3 = T38 was negotiated and is active</div><div>4 = T38 negotiation failed/was rejected</div></div><div><br></div>[1] <a href="https://github.com/asterisk/asterisk/blob/master/channels/sip/include/sip.h#L662" target="_blank">https://github.com/asterisk/asterisk/blob/master/channels/sip/include/sip.h#L662</a><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Check out the new Asterisk community forum at: <a href="https://community.asterisk.org/" rel="noreferrer" target="_blank">https://community.asterisk.org/</a><br>
<br>
New to Asterisk? Start here:<br>
      <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Getting+Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David Cunningham, Voisonics Limited<br><a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>USA: +1 213 221 1092<br>New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>