2009/3/20 Klaus Darilion <klaus.mailingli...@pernau.at> > > > Steve Underwood schrieb: > > Hi Olivier, > > > > Olivier wrote: > >> T.38 says that if the call starts in audio mode it is the called end > >> which should initiate a re-invite to change from audio to T.38. This > >> makes sense, as that is the end which has the best chance of > figuring > >> out if a FAX machine answers the call. In practice many T.38 > >> implementations will send out a re-invite when they are the calling > >> side, so any practical implementation has to allow for this. > >> Clashes are > >> possible, if both ends send re-invite, and this is not always > handled > >> properly > >> > >> > >> Yesterday, with 2 consecutive sendings on the same setup (same fax > >> file, same ATAs, same servers), on the first try, I've seen the > >> reINVITE coming from callee on from the caller on the second try. > >> I don't remember I changed anything between both tries (though I may > >> have done without noticing this). > > That is what typically what happens when the calling end doesn't obey > > the spec. It comes down to a race for who initiates the re-invite first. > > If you are lucky the two ends sort themselves out. If you are unlucky > > you end up with both ends re-inviting, and you may get a call failure. > > This is what I see very often - both sides send reINVITE (overlapping), > both sides reject with 491 (request pending) with the result that the > switch to T.38 failed. I have only once seen handling overlapping > reINVITEs smart (ComISDN client) > > Theoretically it would be perfect if the reINVITE is always triggered by > the callee (as the spec says) - but there are ATAs which need up to 15 > seconds to detect a fax and send reINVITE - and in this cases you > sometimes have to work around by allowing the caller to send reINVITE too.
Linksys 3102 have an option specifying if reINVITE should be inbound, outbound or both. Unfortunately, I couldn't find this option in Patton SmartNodes. > > regards > Klaus > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users