<p dir="ltr">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.</p>
<div class="gmail_quote">On Mar 12, 2014 8:48 AM, "Jeff Pyle" <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<div>
<br></div><div>And, before you ask, I'm not bringing the media through my network. :)</div><div><br></div><div class="gmail_extra"><div><div dir="ltr"><div>
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...</div><div><br></div><div><br></div>
<div>- Jeff</div><div><br></div></div></div>
<br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 3:29 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, then your out of luck here.<br>
Even if there's no SDP in ACK, should be fine.<br>
<br>
On the other hand, if one end doesn't support T.38 and the other end<br>
is insisting on it, the call will fail, so you can just drop the call<br>
there.<br>
<span><font color="#888888"><br>
-ovidiu<br>
</font></span><div><div><br>
On Tue, Mar 11, 2014 at 3:14 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>> wrote:<br>
> By removing the SDP, am I not causing a late-offer behavior? The B-leg<br>
> would expect an SDP on the ACK from the A-leg (which it's not going to get),<br>
> and the A-leg is going to wonder why its T.38 SDP was answered with, say, a<br>
> G.711 one.<br>
><br>
> I've yelled at customers for pulling stuff like that. :)<br>
><br>
><br>
><br>
> - Jeff<br>
><br>
><br>
><br>
> On Tue, Mar 11, 2014 at 2:00 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>> wrote:<br>
>><br>
>> Then remove completely the SDP.<br>
>> The other endpoint should offer the previous codec.<br>
>> The renegotiation should fail and hopefully the call will still stay on<br>
>> ...<br>
>><br>
>> Regards,<br>
>> Ovidiu Sas<br>
>><br>
>><br>
>> On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Ovidiu,<br>
>>><br>
>>> In the case of a pure T.38 SDP offer like this:<br>
>>><br>
>>> v=0<br>
>>> o=- 1394560461 1394560461 IN IP4 192.168.58.4<br>
>>> s=-<br>
>>> c=IN IP4 192.168.58.4<br>
>>> t=0 0<br>
>>> m=image 16426 udptl t38<br>
>>> a=T38FaxVersion:0<br>
>>> a=T38FaxRateManagement:transferredTCF<br>
>>> a=T38FaxFillBitRemoval:0<br>
>>> a=T38FaxTranscodingMMR:0<br>
>>> a=T38FaxTranscodingJBIG:0<br>
>>> a=T38MaxBitRate:14400<br>
>>> a=T38FaxUdpEC:t38UDPRedundancy<br>
>>> a=T38FaxMaxBuffer:600<br>
>>> a=T38FaxMaxDatagram:200<br>
>>><br>
>>><br>
>>> Which codec would I remove?<br>
>>><br>
>>><br>
>>> - Jeff<br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Mar 11, 2014 at 1:44 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Remove the codec and let the re-INVITE go through.<br>
>>>><br>
>>>> Regards,<br>
>>>> Ovidiu Sas<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi Alexander,<br>
>>>>><br>
>>>>> To detect the "image" session in the SDP, you are thinking the same way<br>
>>>>> that I am. The problem I see is how to actually reject the re-INVITE. If I<br>
>>>>> were to do something like a sl_send_reply("488", "Not Acceptable Here"),<br>
>>>>> that would work in the moment, but the CSeq values would be increased by one<br>
>>>>> on side compared to the other. That sounds to me like a recipe for problems<br>
>>>>> in future in-dialog transactions (like BYE).<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> - Jeff<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin<br>
>>>>> <<a href="mailto:mustafin.aleksandr@gmail.com" target="_blank">mustafin.aleksandr@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi, Jeff.<br>
>>>>>><br>
>>>>>> Maybe stream_exists(regexp) in sipmsgops module will be useful for<br>
>>>>>> you.<br>
>>>>>><br>
>>>>>> Best regards,<br>
>>>>>> Alexander Mustafin<br>
>>>>>> <a href="mailto:mustafin.aleksandr@gmail.com" target="_blank">mustafin.aleksandr@gmail.com</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> 11 марта 2014 г., в 20:07, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>><br>
>>>>>> написал(а):<br>
>>>>>><br>
>>>>>> Hello,<br>
>>>>>><br>
>>>>>> Is there anything I can do at the proxy level to prevent a dialog from<br>
>>>>>> reinviting to to T.38? I think I could detect the T.38 attributes easily<br>
>>>>>> enough and respond with a 488, although I'm concerned the CSeq values would<br>
>>>>>> be out of sequence for the next transaction that did make it through the<br>
>>>>>> proxy to the far end. That could cause a problem, no?<br>
>>>>>><br>
>>>>>> Is this something that requires a B2BUA? Is it possible from within<br>
>>>>>> the OpenSIPS B2B modules to do SDP inspection of any sort?<br>
>>>>>><br>
>>>>>><br>
>>>>>> - Jeff<br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> Users mailing list<br>
>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> Users mailing list<br>
>>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Users mailing list<br>
>>>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> VoIP Embedded, Inc.<br>
>>>> <a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Users mailing list<br>
>>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Users mailing list<br>
>>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> VoIP Embedded, Inc.<br>
>> <a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
>><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">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>
><br>
<br>
<br>
<br>
--<br>
VoIP Embedded, Inc.<br>
<a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">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>
</div></div></blockquote></div><br></div></div>
<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>
<br></blockquote></div>