<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="color:rgb(7,55,99)">Hello Henning,</div><div class="gmail_default" style="color:rgb(7,55,99)"><br></div><div class="gmail_default" style="color:rgb(7,55,99)">Thanks for your quick response. Kamailio is complaining about a too long SIP message so migrating to TCP makes sense (I hadn't thought about it).</div><div class="gmail_default" style="color:rgb(7,55,99)"><br></div><div class="gmail_default" style="color:rgb(7,55,99)">I have enabled TCP in kamailio.cfg:</div><div class="gmail_default" style="color:rgb(7,55,99)"><span style="background-color:rgb(30,30,30);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre;color:rgb(86,156,214)">disable_tcp</span><span style="background-color:rgb(30,30,30);color:rgb(212,212,212);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre">=no</span> </div><div class="gmail_default" style="color:rgb(7,55,99)"><br></div><div class="gmail_default" style="color:rgb(7,55,99)">I am using the dispatchers module to identify the gateway endpoints and I have updated it accordingly:</div><div class="gmail_default"><div class="gmail_default" style="color:rgb(7,55,99)">
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:normal;font-family:Monaco;color:rgb(244,244,244);background-color:rgba(0,0,0,0.85)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">1 sip:10.0.1.69:5080;transport=tcp</span></p></div><div style="color:rgb(7,55,99)"><br></div><div style="color:rgb(7,55,99)">and in my invite resolver I am forcing the sending socket to be tcp as well. </div><div style="color:rgb(7,55,99)"><br></div><div><div><font color="#073763">route[INVITE_RESOLVER] {</font></div><div><font color="#073763"><span style="white-space:pre"> </span>xlog("L_DBG", "[R-INVITE-RESOLVER:$ci] Entering INVITE resolver\n");</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> route(CHECK_DID);</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> # Use main asterisk dispatcher set</font></div><div><font color="#073763"> $var(disp_set) = 1;</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> # Store diversion reason</font></div><div><font color="#073763"> redis_cmd("abn", "SET $fd-div $dir", "r");</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> # Trim SIP messages of useless headers</font></div><div><font color="#073763"> remove_hf_re("^X-");</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> $fs = "tcp:PRIVATE_IP:5080";</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] Processing dispatcher set $var(disp_set)\n");</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> if(!ds_select_domain("$var(disp_set)", "4")) {</font></div><div><font color="#073763"> # This should only happen if the route set is empty.</font></div><div><font color="#073763"> sl_send_reply("503", "Out of Gateways");</font></div><div><font color="#073763"> xlog("L_ERR", "[R-INVITE-RESOLVER:$ci] !> "</font></div><div><font color="#073763"> "No gateways available!\n");</font></div><div><font color="#073763"> exit;</font></div><div><font color="#073763"> }</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] -> "</font></div><div><font color="#073763"> "Selected gateway: $rd:$rp\n");</font></div><div><font color="#073763"><br></font></div><div><font color="#073763"> t_on_failure("DISPATCHER_ROLLOVER");</font></div><div><font color="#073763"> route(INVITE_POSTROUTE);</font></div><div><font color="#073763">}</font></div></div><div style="color:rgb(7,55,99)"><br></div><div style="color:rgb(7,55,99)">Are there any resources that I can check to make sure that I am not missing anything? Since this is not working, I am suspecting it is related with the Asterisk side of things but that should be handled in another mail list.</div><div style="color:rgb(7,55,99)"><br></div><div style="color:rgb(7,55,99)">Thanks for your support,</div><div style="color:rgb(7,55,99)"><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 9:29 PM Henning Westerholt <<a href="mailto:hw@kamailio.org">hw@kamailio.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Montag, 29. Oktober 2018, 17:27:27 CET schrieb Joan Salvatella:<br>
> [..]<br>
> - *Message Too Long Error:* Since Twilio uses long URIs to define its<br>
> resources, the SIP messages being handled by Kamailio are sometimes too<br>
> big and generate a "Message Too Long error". I have been able to<br>
> temporarily patch this removing unused headers using remove_hf_re and<br>
> remove_hf but it still fails from time to time. Is there a way to split the<br>
> UDP packet to mitigate this issue? or what other options could be<br>
> considered?<br>
<br>
Hello Joan,<br>
<br>
I don't understand the error description completely. Does Kamailio complain <br>
about a to long header field or a too long SIP message?<br>
<br>
About the question regarding the options - have you thought about using TCP?<br>
<br>
Best regards, Henning<br>
<br>
-- <br>
Henning Westerholt - <a href="https://skalatan.de/blog/" rel="noreferrer" target="_blank">https://skalatan.de/blog/</a><br>
Kamailio security assessment - <a href="https://skalatan.de/de/assessment" rel="noreferrer" target="_blank">https://skalatan.de/de/assessment</a><br>
</blockquote></div>