<div dir="ltr">Then remove completely the SDP.<div>The other endpoint should offer the previous codec.</div><div>The renegotiation should fail and hopefully the call will still stay on ...</div><div><br></div><div>Regards,</div>
<div>Ovidiu Sas</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 1:56 PM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div dir="ltr"><div>Hi Ovidiu,</div><div><br></div><div>In the case of a pure T.38 SDP offer like this:</div>
<div><br></div></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_extra"><div><div><div><div>v=0</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>o=- 1394560461 1394560461 IN IP4 192.168.58.4</div></div></div></div></div><div class="gmail_extra">
<div><div><div><div>s=-</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>c=IN IP4 192.168.58.4</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>t=0 0</div></div></div></div>
</div><div class="gmail_extra"><div><div><div><div>m=image 16426 udptl t38</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38FaxVersion:0</div></div></div></div></div><div class="gmail_extra">
<div><div><div><div>a=T38FaxRateManagement:transferredTCF</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38FaxFillBitRemoval:0</div></div></div></div></div><div class="gmail_extra"><div><div>
<div><div>a=T38FaxTranscodingMMR:0</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38FaxTranscodingJBIG:0</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38MaxBitRate:14400</div>
</div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38FaxUdpEC:t38UDPRedundancy</div></div></div></div></div><div class="gmail_extra"><div><div><div><div>a=T38FaxMaxBuffer:600</div></div></div></div></div>
<div class="gmail_extra"><div><div><div><div>a=T38FaxMaxDatagram:200</div></div></div></div></div></blockquote><div class="gmail_extra"><div><div dir="ltr"><div><br></div><div>Which codec would I remove?</div><span class="HOEnZb"><font color="#888888"><div>
<br></div>
<div><br></div><div>- Jeff</div><div><br></div></font></span></div></div><div><div class="h5">
<br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 1:44 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Remove the codec and let the re-INVITE go through.<div><br></div><div>Regards,</div><div>Ovidiu Sas<br><div><br></div></div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">
On Tue, Mar 11, 2014 at 1:42 PM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div dir="ltr">
<div>Hi Alexander,</div><div><br></div><div>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).</div>
<span><font color="#888888">
<div><br></div><div><br></div><div><br></div><div>- Jeff</div><div><br></div><div>
<br></div></font></span></div></div><div><div>
<br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 12:58 PM, Alexander Mustafin <span dir="ltr"><<a href="mailto:mustafin.aleksandr@gmail.com" target="_blank">mustafin.aleksandr@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi, Jeff.<div><br></div>
<div>Maybe stream_exists(regexp) in sipmsgops module will be useful for you.<div>
<br></div><div>
<div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;white-space:normal;font-family:Helvetica;word-wrap:break-word;word-spacing:0px">
<div>Best regards,</div><div>Alexander Mustafin</div><div><a href="mailto:mustafin.aleksandr@gmail.com" target="_blank">mustafin.aleksandr@gmail.com</a></div><div><br></div></div><br><br>
</div>
<br><div><div>11 марта 2014 г., в 20:07, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>> написал(а):</div><br><blockquote type="cite"><div><div><div dir="ltr">
<div><div dir="ltr"><div>Hello,</div><div><br></div><div>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?</div>
<div><br></div><div>Is this something that requires a B2BUA? Is it possible from within the OpenSIPS B2B modules to do SDP inspection of any sort?</div><div><br></div><div><br></div><div>- Jeff</div><div><br></div></div>
</div>
</div></div></div>
_______________________________________________<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>
</blockquote></div><br></div></div><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></blockquote></div><br></div></div></div></div>
<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></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>VoIP Embedded, Inc.<br><a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a>
</font></span></div>
<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></blockquote></div><br></div></div></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><br><br clear="all"><div><br></div>-- <br>VoIP Embedded, Inc.<br><a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a>
</div>