Hi Theo,<div>I had a look on your patch and I tried it on asterisk-1.4.36.</div><div>Unfortunately it doesn't solve my problem which is related to an audio call with no compatible codecs. </div><div>My scenario is the following:</div>
<div>1) user A has a set of allowed codecs configured on Asterisk (let's say ulaw and g729)</div><div>2) user A sends an INVITE with none of the allowed codecs in the SDP (let's say is sending alaw) and no T.38 </div>
<div>3) Asterisk does not reject the call with "488 - Not acceptable here" but make the call to the extension and return an SDP with no codec.</div><div><br></div><div>As I wrote in my previous mail the problem is present only when t38 is globally enabled. </div>
<div>What the patch doesn't change in the original chan_sip.c is at row 5757 of the patched file:</div><div><div><br></div><div>5755: if (!newjointcapability) {</div><div>5756: /* If T.38 was not negotiated either, totally bail out... */</div>
</div><div>5757: if (!p->t38.jointcapability || !udptlportno) {<div>5758: ast_log(LOG_NOTICE, "No compatible codecs, not accepting this offer!\n");</div><div>5759: /* Do NOT Change current setting */</div>
<div>5760: return -1;</div><div><br></div><div>If t38 is globally enabled the condition is never matched regardless the SDP contained a FAX request or not.</div><div>That's why I thought to change it with </div>
<div><br></div><div> if (!p->t38.jointcapability || !udptlportno || t38.state == T38_DISABLED)</div><div><br></div><div>or something similar to check if the call was effectively a Fax only call. Unfortunately I'm not a big expert of T38 and its problems.</div>
<div>I'm trying your patch with this further modification. Till now I've tested some few scenarios:</div><div><br></div><div>1) call with no compatible codec (that's was my main interest)</div><div>2) call with RTP and T38</div>
<div>3) T38 only call</div><div><br></div><div>The tests were ok (in the first one I got a 488, as desired) but, I repeat, my knowledge of T38 is not enough...</div><div><br></div><div>Kind regards,</div><div><br></div><div>
Federico Cabiddu </div></div><div><div class="gmail_quote">2010/9/24 Theo Belder <span dir="ltr"><<a href="mailto:tbelder@gmail.com">tbelder@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Federico,<br><br>We have encoutered the same problem. We have made a patch for this, so you can send T38 only invites. You can find the patch here:<br><a href="https://issues.asterisk.org/view.php?id=17966" target="_blank">https://issues.asterisk.org/view.php?id=17966</a>. You should grep the latest patch (rev3)!<br>
<br>BR. Theo<br><br><br><br><div class="gmail_quote">2010/9/22 federico cabiddu <span dir="ltr"><<a href="mailto:federico.cabiddu@gmail.com" target="_blank">federico.cabiddu@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><div></div><div class="h5">
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">federico cabiddu</b> <span dir="ltr"><<a href="mailto:federico.cabiddu@gmail.com" target="_blank">federico.cabiddu@gmail.com</a>></span><br>
Date: 2010/9/22<br>Subject: [asterisk-users] T38 and codecs negotiation<br>To: <a href="mailto:asterisk-users@lists.digium.com" target="_blank">asterisk-users@lists.digium.com</a><br><br><br>Hi,<div>I'm working with asterisk 1.4.35 and found an issue regarding codecs negotiation when T38 is enabled (t38pt_udptl=yes).</div>
<div>In particular if the INVITE sdp contains no allowed codec the call is not rejected with "488 - Not acceptable here" but it goes through and the 200 OK SDP is as follows:</div>
<div><br></div><div><div>v=0</div><div>o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx</div><div>s=session</div><div>c=IN IP4 xxx.xxx.xxx.xxx</div><div>t=0 0</div><div>m=audio xxxxx RTP/AVP </div><div>a=silenceSupp:off - - - -</div>
<div>a=sendrecv</div><div><br></div><div>or</div><div><br></div><div><div>v=0</div><div>o=root 27285 27285 IN IP4 xxx.xxx.xxx.xxx</div><div>s=session</div><div>c=IN IP4 xxx.xxx.xxx.xxx</div><div>t=0 0</div><div>m=audio xxxxx RTP/AVP 96</div>
<div>a=rtpmap:96 telephone-event/8000</div><div>a=fmtp:96 0-15</div><div>a=silenceSupp:off - - - -</div><div>a=sendrecv</div><div><br></div><div>if in the originating INVITE there was the a line for telephone-event mapping.</div>
<div>Looking chan_sip.c I understood that the problem is related to t38 capabilities and in particular at row 5636:</div><div><div><br></div><div>if (!newjointcapability) {</div><div> /* If T.38 was not negotiated either, totally bail out... */</div>
<div> if (!p->t38.jointcapability || !udptlportno) {</div><div> ast_log(LOG_NOTICE, "No compatible codecs, not accepting this offer!\n");</div><div> /* Do NOT Change current setting */</div>
<div> return -1;</div><div> } else {</div><div> if (option_debug > 2)</div><div> ast_log(LOG_DEBUG, "Have T.38 but no audio codecs, accepting offer anyway\n");</div>
<div> }</div><div> }</div><div><br></div><div>As I understand if t38 is globally enabled p->t38.jointcapability and udptlportno are always true even so the call is never rejected.</div><div>As this behavior caused me some problems with a customer I modified, for the moment, the line 5638 as follows:</div>
<div><br></div><div>if (!p->t38.jointcapability || !udptlportno || p->t38.state == T38_DISABLED)</div><div><br></div><div>cause if I understand well the code if there is no fax request in the INVITE SDP p->t38.state is set to T38_DISABLED.</div>
<div>This did the trick for me but I don't know the implications of such change and if it is correct to manage it this way.</div><div><br></div><div>Kind regards,</div><div><br></div><div>Federico Cabiddu</div><div><br>
</div></div></div></div>
</div><br>
<br></div></div>--<div class="im"><br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br></div>
asterisk-dev mailing list<div class="im"><br>
To UNSUBSCRIBE or update options visit:<br></div>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>