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. 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
