<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 20, 2013 at 12:26 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>19 sep 2013 kl. 18:45 skrev SVN commits to the Digium repositories <<a href="mailto:svn-commits@lists.digium.com" target="_blank">svn-commits@lists.digium.com</a>>:</div>
<div class="im"><br><blockquote type="cite"><span style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">Prior to this patch, Asterisk would incorrectly use the previous endpoint</span><br style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">addresses in SDP in spite of providing its own port. T38 is never meant to</span><br style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">be done through directmedia and Asterisk should always be in the media path</span><br style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:monospace;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">for these streams.</span></blockquote>
</div></div><br><div>Just being curious: Why was T.38 never meant to use directmedia? Any technichal reasons in the protocol?</div><div>Or just something missing in our code?</div><span class="HOEnZb"><font color="#888888"><div>
<br></div></font></span></div></blockquote><div><br></div><div style>It's actually really rather difficult to get right reliably. Unlike audio, where some audio packets can be dropped during the re-negotiation for directmedia, you don't want to lose or other perturb any of the T.38 fax packets once the sending device starts transmitting to Asterisk. We know that in some scenarios, directmedia set up of a media stream can take a measurable amount of time - sometimes, even a second or two. What's more, since you can't predict when both devices will get the re-INVITE, often a device will send media to its new target before that device is ready - and devices will usually drop media received from endpoints they don't recognize (to avoid the 'media injection attack' scenario).</div>
<div style><br></div><div style>That length of time - and dropping packets - could play havoc with a T.38 fax stream. For example, say that a transmitting device has established a fax session passing through Asterisk and has started long training to determine the fax rate. While doing so, it receives a re-INVITE from Asterisk to send its fax media stream directly to another device. Does it re-start the training with the new device? Does it restart the entire transmission? Does it fail the training and try again with the new device? If so, how does it know what state the receiving device is in? Does it assume that Asterisk has relayed its received fax packets already? If so, does it assume that Asterisk has sent all of them - or some subset?</div>
<div style><br></div><div style>Unlike audio, every packet during a T.38 fax transmission matters to some extent - either as control information or as part of the image. This is why fax is temperamental and hard to get right in even the best of scenarios. Direct media involving fax *may* work in some very specific scenarios, but is much more likely to lead to incredibly difficult to diagnose problems. Hence Mark's/Josh's/my insistence that - barring a *very* good patch that implements it, testing, and a very good explanation of how it avoids and/or handles various edge cases - it's better to just not do direct media for fax. (I'd go so far as to say that even if such a patch were possible, investing such time on fax is insane, but that's just me).</div>
<div style><br></div><div style>Hope that clears it up for everyone!</div><div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div>
<div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>