<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Iņaki, Dave,</div><div><br></div><div>Thanks for the feedback, on a Sunday no less! This gives me enough confidence to give it a try without the fear of causing a tear in the universe.</div><div><br></div><div>Here's the whole story (at the risk of not including a lot of Opensips info). I use a lot of Adtran TA900-series PRI and analog gateways with great success, including with T.38. Most of the gateways my carrier partners are using are Sonus GSX 9000-series. They run similar configs with it comes to T.38.</div><div><br></div><div>The Sonus nor the Adtrans indicate T.38 support in the initial SDPs attached to the initial INVITE or 200 OK. On the Adtran in particular, I can control which tones it must detect to send a reinvite to G.711 or T.38. The default config is "any", including:</div><div><br></div><div><blockquote style="margin:0 0 0 40px; border:none; padding:0px;"><div>voice fax-tone modem-passthrough v25-ans</div><div>voice fax-tone modem-passthrough v25-ans-pr</div><div>voice fax-tone modem-passthrough v8-ansam</div><div>voice fax-tone modem-passthrough v8-ansam-pr</div><div>voice fax-tone modem-passthrough t30-cng</div><div>voice fax-tone modem-passthrough v21-preamble</div><div>voice fax-tone t38 v25-ans</div><div>voice fax-tone t38 v25-ans-pr</div><div>voice fax-tone t38 v8-ansam</div><div>voice fax-tone t38 v8-ansam-pr</div><div>voice fax-tone t38 t30-cng</div><div>voice fax-tone t38 v21-preamble</div></blockquote></div><div><br></div><div>The "modem-passthrough" section will cause a reinvite to G.711 and the t38 section, well, to T.38. In this case with all tones defined for both, T.38 will take precedence. This kind of flexibility is nice because it allows the co-existance of low speed modem connections and T.38 faxing at the expense of a slightly longer delay before the T.38 reinvite is sent.</div><div><br></div><div>T.38 must be enabled on the appropriate voice interface for a reinvite to be sent or accepted. If a T.38 reinvite is received without it being enabled on the interface, the Adtran sends a 488. I've never seen a call get dropped with a BYE at this stage, rather the call continues without modifying the audio session. The Adtran can be configured for G711 failover in the event a T.38 reinvite is unsuccessful.</div><div><br></div><div>As I said I've never seen a T.38 session start without a reinvite. I have seen only unsupported codecs come in. In a reinvite scenario, this will cause a 488. On an initial INVITE, however, the Adtrans send a 415 Unsupported media type. I don't have enough experience with different types of gateways to know if this is normal behavior or not.</div><div><br></div><div>I'll take a look at the FaxBack implementation as time allows. Recommendations are always appreciated.</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Dave Singer <<a href="mailto:dave.singer@wideideas.com">dave.singer@wideideas.com</a>><br><span style="font-weight:bold">Reply-To: </span> OpenSIPS users mailling list <<a href="mailto:users@lists.opensips.org">users@lists.opensips.org</a>><br><span style="font-weight:bold">Date: </span> Sun, 6 Mar 2011 17:47:53 -0500<br><span style="font-weight:bold">To: </span> OpenSIPS users mailling list <<a href="mailto:users@lists.opensips.org">users@lists.opensips.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [OpenSIPS-Users] Stopping a T.38 reinvite with Opensips loose_route()<br></div><div><br></div>JP,<br><br>The two end points have to agree on an RTP protocol.<br>You may look at the SDP in the initial INVITEs to see if T.38 is offered and if it is, remove it.<br>Also if the re-INVITE contains G711 along with the T.38 you should be able to just remove the T.38.<br>
That should accomplish the same effect as the customer disabling T.38.<br><br>FYI: FaxBack has a very reliable T.38 implementation
NET SatisFAXtion that we have been using for quite some time.<br><br>Dave<br><br><div class="gmail_quote">On Sun, Mar 6, 2011 at 1:52 PM, Iņaki Baz Castillo <span dir="ltr"><<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">2011/3/6 Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>>:<br><div class="im">> Unfortunately the customer cannot disable T.38. I'd like to be able to<br>
> reject the reinvite with a send_reply("488", "Not acceptable here") within<br>
> the loose_route() section. Is this legit, or am I going to break things,<br>
> like getting the two endpoints' CSeqs out of sync?<br><br></div>You are not going to break CSeq at all. The proxy is able to reject<br>
in-dialog requests depending on local policy. When the UA receives 488<br>
it does know that, in case of a new in-dialog request, it must use a<br>
greater CSeq, which of course will be valid in the other UA (it must<br>
be just higher than previous one, no matter how much higher).<br><br>
But in your case, the problem is that when your UA receives the 488 it<br>
will probably send a BYE (it's the usual policy when a re-INVITE is<br>
rejected). But you can try it. You will not break SIP protocol at all.<br><font color="#888888"><br>
--<br>
Iņaki Baz Castillo<br>
<<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>><br><br>
_______________________________________________<br>
Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></font></blockquote></div><br></span></body></html>