On 01/08/2013, at 2:20 PM, Zoltán Fekete <[email protected]> wrote:
>
> 2013/8/1 Joshua Colp <[email protected]>
> Larry Moore wrote:
> On 31/07/2013 8:08 PM, Joshua Colp wrote:
> Zoltán Fekete wrote:
> Thank You Larry!
>
> I have discussed with my provider. They are not able to insert the
> T38MaxBitRate value into the sip answer. :(
> https://gist.github.com/anonymous/6120148 (line 559)
>
> That means we are not able to passtrough T38 Faxes with any asterisk
> version at all?
> What do you mean? Am I able to modify and compile the source? Is it
> compicated? (I'm not a developer)
>
> Based on the SDP in your gist the remote implementation has given no
> attributes with the T.38 stream which makes it pretty broken
> (T38FaxRateManagement is mandatory) and fun. The two hard parts really
> would be 1. Modifying Asterisk in a sane fashion to cope and 2.
> Determining the exact settings to make the implementation happy.
> Defaults as defined in the spec are fine and good, but my experience has
> taught me to throw those out the window when it comes to actual
> implementations.
>
>
> It would seem that having a configurable option would be an idea for
> this scenario.
>
> 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.
>
> My testing with Asterisk 1.8 and T.38, I obserevd that setting
> FAXOPT(minrate) or FAXOPT(maxrate)had no effect, I concluded that when
> Astrerisk is receiving it uses hard coded values - is this a sane thing
> to do?!
>
> 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.
>
> I would even say it's a bug that the negotiation doesn't fail, since the
> remote side isn't providing a mandatory attribute.
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
>
>
> Yes you're right! As I know FAXOPT() value affect only when asterisk woks as
> gateway.
> We need passtrouh because my endpoints and also my provider supports T38.
>
> https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway
> "Using T.38 Gateway mode
> 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 transparent
> T.38 passthrough."
>
> The main problem is that I can't use G711 for the entire fax session because
> the endpoints has 20-30ms response time.
>
> 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?
> 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.
>
Have you tried setting in your sip.conf for your provider t38pt_udptl=no whilst
having the gateway option enabled?
Sorry I cant test this myself.
Cheers,
Larry.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
