<html><head></head><body bgcolor="#FFFFFF"><div><br><br>On 01/08/2013, at 2:20 PM, Zoltán Fekete <<a href="mailto:blaxy@gyoz.info">blaxy@gyoz.info</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/8/1 Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Larry Moore wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 31/07/2013 8:08 PM, Joshua Colp wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Zoltán Fekete wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thank You Larry!<br>
<br>
I have discussed with my provider. They are not able to insert the<br>
T38MaxBitRate value into the sip answer. :(<br>
<a href="https://gist.github.com/anonymous/6120148" target="_blank">https://gist.github.com/<u></u>anonymous/6120148</a> (line 559)<br>
<br>
That means we are not able to passtrough T38 Faxes with any asterisk<br>
version at all?<br>
What do you mean? Am I able to modify and compile the source? Is it<br>
compicated? (I'm not a developer)<br>
</blockquote>
<br>
Based on the SDP in your gist the remote implementation has given no<br>
attributes with the T.38 stream which makes it pretty broken<br>
(T38FaxRateManagement is mandatory) and fun. The two hard parts really<br>
would be 1. Modifying Asterisk in a sane fashion to cope and 2.<br>
Determining the exact settings to make the implementation happy.<br>
Defaults as defined in the spec are fine and good, but my experience has<br>
taught me to throw those out the window when it comes to actual<br>
implementations.<br>
<br>
</blockquote>
<br>
It would seem that having a configurable option would be an idea for<br>
this scenario.<br>
</blockquote>
<br>
That implies it would solve the problem, which my gut and experience tells me... it wouldn't. I think the T.38 implementation is just cobbled together and without knowing exactly how it behaves getting it to work would likely be a nightmare (trust me, I've spent time in those deep dark reaches). Throwing assumptions and defaults at it to try to make it work is of course an option.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
My testing with Asterisk 1.8 and T.38, I obserevd that setting<br>
FAXOPT(minrate) or FAXOPT(maxrate)had no effect, I concluded that when<br>
Astrerisk is receiving it uses hard coded values - is this a sane thing<br>
to do?!<br>
</blockquote>
<br>
When Asterisk is receiving the stack implementation offers what it wants, with the ability to override. So Asterisk doesn't hard code those values, the stack provides them. What is hard coded is the default values if none are received.<br>
<br>
I would even say it's a bug that the negotiation doesn't fail, since the remote side isn't providing a mandatory attribute.<br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
--<br>
______________________________<u></u>______________________________<u></u>_________<br><br></blockquote><div><br></div><div>Yes you're right! As I know FAXOPT() value affect only when asterisk woks as gateway. </div>
<div>We need passtrouh because my endpoints and also my provider supports T38.</div><div><br></div><div><h4 id="T.38FaxGateway-UsingT.38Gatewaymode" style="margin:1.2em 0px 0.3em;font-size:1.2em;line-height:20px;color:rgb(0,0,0);font-family:Arial,sans-serif">
<a href="https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway">https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway</a><br></h4><h4 id="T.38FaxGateway-UsingT.38Gatewaymode" style="margin:1.2em 0px 0.3em;font-size:1.2em;line-height:20px;color:rgb(0,0,0);font-family:Arial,sans-serif">
"Using T.38 Gateway mode</h4><p style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">T.38 Gateway mode should be used when one leg of a call is not capable of T.38 mode. In the event that both legs are capable and Gateway mode is configured, then the Gateway will step out of the way, allowing <u>transparent T.38 passthrough</u>."</p>
</div><div><br></div><div>The main problem is that I can't use G711 for the entire fax session because the endpoints has 20-30ms response time.</div><div><br></div><div>When I try to use my Asterisk as FAXOPT gateway (endpoint leg T38 and provider leg G711) can I force somehow to not accept the T38 re-INVITEs from the provider? </div>
<div>They have ~1ms response time, so G711 on that leg would be fine but they also detect fax CED tones and sends the re-INVITEs.</div><div><br></div></div></div></div></div></blockquote><div><br></div><div>Have you tried setting in your sip.conf for your provider t38pt_udptl=no whilst having the gateway option enabled?</div><div><br></div><div>Sorry I cant test this myself.</div><div><br></div><div>Cheers,</div><div><br></div><div>Larry.</div></body></html>