[OpenSIPS-Users] Prevent re-INVITE to T.38

Wed Mar 12 16:32:59 CET 2014

T.38 v2 supports up to 14.4k (V.17), v3 supports 33.6k (V.34).  None of my
carrier partners' gateways support T.38 v3.

A SuperG3 capable fax machine supports up to 33.6k (V.34).  Let's say we
have two SG3 machines trying to talk to each other with an IP/T.38 v2 link
in the middle.  Since the gateways are reconstructing all the T.30 info,
the term side spoofs the DIS to indicate a maximum supported speed of V.17
14.4k, so the originating side's DCS says, "Sure, 14.4 is it!"  So, there
shouldn't be any problem if two faster machines communicating at a max of
14.4k V.17 through a T.38 link.

Speed isn't the issue.  In fact, in some cases, it can be our friend.  Read
on...

I think it's more a of a general compatibility issue.  On our own network
we've found G.711 with large, fixed jitter buffers is more likely to
negotiate successfully than a T.38 call.  The difference in success rate
isn't huge but it's enough to cause us to use G.711 by default.

If the call is up long enough to cause the modems' HDLC sync to slip
because of jitter buffer under/overrun (or something like that), the call
will blow up.  On our network using a lot of Adtran TA-series gateways,
that happens in no less than 45 minutes normall, sometimes as long as hours
or more.  And since on G.711 it seems to be a time related issue, we
encourage our customers' machines to run at full 33.6k V.34 speeds.  In
other words, get as many pages through as possible before HDLC skew breaks
the call.  This is contrary to most advice you'll find to slow machines to
V.29 9600.  I find if the network is properly configured, V.34 33.6k is a
stable reality.

Anyway, back to the issue at hand.  T.38 negotiations are rather heavy
handed compared to letting G.711 through.  So, even on carrier gateway to
carrier gateway calls setups, we find G.711 more stable.  That's why I'm
looking for a way to 488 the re-invite from one side or the other to
preserve the G.711 state.  I suppose I could insert a Freeswitch instance
in the middle to inspect the SDP, but that's ... not my first choice.

Does that make sense?  :)

- Jeff

On Wed, Mar 12, 2014 at 11:17 AM, Ovidiu Sas <osas at voipembedded.com> wrote:

> It must be the new fax machines that are using high speeds that are not
> supported by T.38. Striping SDP completely may create issues ... IIRC you
> are not allowed to have no SDP in INVITEs.
> On Mar 12, 2014 8:48 AM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:
>
>> Our use case is a call forward from an inbound carrier gateway to an
>> outbound one.  Both do support T.38.  In fact, that's the problem.  We've
>> seen much higher success rates with fax forwards if both sides stay G.711.
>>  Quite interesting considering in many cases both the originating and
>> terminating gateways are Sonus GSX, although on different carrier networks.
>>
>> And, before you ask, I'm not bringing the media through my network.  :)
>>
>> I'm not quite ready to test yet.  When I am, I'll try the SDP stripping
>> approach and see how the gateways behave.  Perhaps if I strip the SDP in
>> both the offer and the answer...
>>
>>
>> - Jeff
>>
>>
>>
>> On Tue, Mar 11, 2014 at 3:29 PM, Ovidiu Sas <osas at voipembedded.com>wrote:
>>
>>> Well, then your out of luck here.
>>> Even if there's no SDP in ACK, should be fine.
>>>
>>> On the other hand, if one end doesn't support T.38 and the other end
>>> is insisting on it, the call will fail, so you can just drop the call
>>> there.
>>>
>>> -ovidiu
>>>
>>> On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>> wrote:
>>> > By removing the SDP, am I not causing a late-offer behavior?  The B-leg
>>> > would expect an SDP on the ACK from the A-leg (which it's not going to
>>> get),
>>> > and the A-leg is going to wonder why its T.38 SDP was answered with,
>>> say, a
>>> > G.711 one.
>>> >
>>> > I've yelled at customers for pulling stuff like that.  :)
>>> >
>>> >
>>> >
>>> > - Jeff
>>> >
>>> >
>>> >
>>> > On Tue, Mar 11, 2014 at 2:00 PM, Ovidiu Sas <osas at voipembedded.com>
>>> wrote:
>>> >>
>>> >> Then remove completely the SDP.
>>> >> The other endpoint should offer the previous codec.
>>> >> The renegotiation should fail and hopefully the call will still stay
>>> on
>>> >> ...
>>> >>
>>> >> Regards,
>>> >> Ovidiu Sas
>>> >>
>>> >>
>>> >> On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>> >> wrote:
>>> >>>
>>> >>> Hi Ovidiu,
>>> >>>
>>> >>> In the case of a pure T.38 SDP offer like this:
>>> >>>
>>> >>> v=0
>>> >>> o=- 1394560461 1394560461 IN IP4 192.168.58.4
>>> >>> s=-
>>> >>> c=IN IP4 192.168.58.4
>>> >>> t=0 0
>>> >>> m=image 16426 udptl t38
>>> >>> a=T38FaxVersion:0
>>> >>> a=T38FaxRateManagement:transferredTCF
>>> >>> a=T38FaxFillBitRemoval:0
>>> >>> a=T38FaxTranscodingMMR:0
>>> >>> a=T38FaxTranscodingJBIG:0
>>> >>> a=T38MaxBitRate:14400
>>> >>> a=T38FaxUdpEC:t38UDPRedundancy
>>> >>> a=T38FaxMaxBuffer:600
>>> >>> a=T38FaxMaxDatagram:200
>>> >>>
>>> >>>
>>> >>> Which codec would I remove?
>>> >>>
>>> >>>
>>> >>> - Jeff
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas <osas at voipembedded.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Remove the codec and let the re-INVITE go through.
>>> >>>>
>>> >>>> Regards,
>>> >>>> Ovidiu Sas
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle <jpyle at fidelityvoice.com
>>> >
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Hi Alexander,
>>> >>>>>
>>> >>>>> To detect the "image" session in the SDP, you are thinking the
>>> same way
>>> >>>>> that I am.  The problem I see is how to actually reject the
>>> re-INVITE.  If I
>>> >>>>> were to do something like a sl_send_reply("488", "Not Acceptable
>>> Here"),
>>> >>>>> that would work in the moment, but the CSeq values would be
>>> increased by one
>>> >>>>> on side compared to the other.  That sounds to me like a recipe
>>> for problems
>>> >>>>> in future in-dialog transactions (like BYE).
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> - Jeff
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin
>>> >>>>> <mustafin.aleksandr at gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Hi, Jeff.
>>> >>>>>>
>>> >>>>>> Maybe stream_exists(regexp) in sipmsgops module will be useful for
>>> >>>>>> you.
>>> >>>>>>
>>> >>>>>> Best regards,
>>> >>>>>> Alexander Mustafin
>>> >>>>>> mustafin.aleksandr at gmail.com
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 11 марта 2014 г., в 20:07, Jeff Pyle <jpyle at fidelityvoice.com>
>>> >>>>>> написал(а):
>>> >>>>>>
>>> >>>>>> Hello,
>>> >>>>>>
>>> >>>>>> Is there anything I can do at the proxy level to prevent a dialog
>>> from
>>> >>>>>> reinviting to to T.38?  I think I could detect the T.38
>>> attributes easily
>>> >>>>>> enough and respond with a 488, although I'm concerned the CSeq
>>> values would
>>> >>>>>> be out of sequence for the next transaction that did make it
>>> through the
>>> >>>>>> proxy to the far end.  That could cause a problem, no?
>>> >>>>>>
>>> >>>>>> Is this something that requires a B2BUA?  Is it possible from
>>> within
>>> >>>>>> the OpenSIPS B2B modules to do SDP inspection of any sort?
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> - Jeff
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Users mailing list
>>> >>>>>> Users at lists.opensips.org
>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Users mailing list
>>> >>>>>> Users at lists.opensips.org
>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Users mailing list
>>> >>>>> Users at lists.opensips.org
>>> >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> VoIP Embedded, Inc.
>>> >>>> http://www.voipembedded.com
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Users mailing list
>>> >>>> Users at lists.opensips.org
>>> >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Users mailing list
>>> >>> Users at lists.opensips.org
>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> VoIP Embedded, Inc.
>>> >> http://www.voipembedded.com
>>> >>
>>> >> _______________________________________________
>>> >> Users mailing list
>>> >> Users at lists.opensips.org
>>> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
> _______________________________________________
> Users mailing list
> 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/20140312/0320a7aa/attachment.htm>