Iñaki, Dave, 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.
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. 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: voice fax-tone modem-passthrough v25-ans voice fax-tone modem-passthrough v25-ans-pr voice fax-tone modem-passthrough v8-ansam voice fax-tone modem-passthrough v8-ansam-pr voice fax-tone modem-passthrough t30-cng voice fax-tone modem-passthrough v21-preamble voice fax-tone t38 v25-ans voice fax-tone t38 v25-ans-pr voice fax-tone t38 v8-ansam voice fax-tone t38 v8-ansam-pr voice fax-tone t38 t30-cng voice fax-tone t38 v21-preamble 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. 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. 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. I'll take a look at the FaxBack implementation as time allows. Recommendations are always appreciated. - Jeff From: Dave Singer <[email protected]<mailto:[email protected]>> Reply-To: OpenSIPS users mailling list <[email protected]<mailto:[email protected]>> Date: Sun, 6 Mar 2011 17:47:53 -0500 To: OpenSIPS users mailling list <[email protected]<mailto:[email protected]>> Subject: Re: [OpenSIPS-Users] Stopping a T.38 reinvite with Opensips loose_route() JP, The two end points have to agree on an RTP protocol. You may look at the SDP in the initial INVITEs to see if T.38 is offered and if it is, remove it. Also if the re-INVITE contains G711 along with the T.38 you should be able to just remove the T.38. That should accomplish the same effect as the customer disabling T.38. FYI: FaxBack has a very reliable T.38 implementation NET SatisFAXtion that we have been using for quite some time. Dave On Sun, Mar 6, 2011 at 1:52 PM, Iñaki Baz Castillo <[email protected]<mailto:[email protected]>> wrote: 2011/3/6 Jeff Pyle <[email protected]<mailto:[email protected]>>: > Unfortunately the customer cannot disable T.38. I'd like to be able to > reject the reinvite with a send_reply("488", "Not acceptable here") within > the loose_route() section. Is this legit, or am I going to break things, > like getting the two endpoints' CSeqs out of sync? You are not going to break CSeq at all. The proxy is able to reject in-dialog requests depending on local policy. When the UA receives 488 it does know that, in case of a new in-dialog request, it must use a greater CSeq, which of course will be valid in the other UA (it must be just higher than previous one, no matter how much higher). But in your case, the problem is that when your UA receives the 488 it will probably send a BYE (it's the usual policy when a re-INVITE is rejected). But you can try it. You will not break SIP protocol at all. -- Iñaki Baz Castillo <[email protected]<mailto:[email protected]>> _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
