[OpenSIPS-Users] Stopping a T.38 reinvite with Opensips loose_route()

[Jeff Pyle]

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 <dave.singer at wideideas.com<mailto:dave.singer at wideideas.com>>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Date: Sun, 6 Mar 2011 17:47:53 -0500
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
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 <ibc at aliax.net<mailto:ibc at aliax.net>> wrote:
2011/3/6 Jeff Pyle <jpyle at fidelityvoice.com<mailto:jpyle at fidelityvoice.com>>:
> 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
<ibc at aliax.net<mailto:ibc at aliax.net>>

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110306/1292488d/attachment-0001.htm>