[SR-Users] Diversion headers access and message too long error

[Joan Salvatella]

Hello Henning,

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).

I have enabled TCP in kamailio.cfg:
disable_tcp=no

I am using the dispatchers module to identify the gateway endpoints and I
have updated it accordingly:

1 sip:10.0.1.69:5080;transport=tcp

and in my invite resolver I am forcing the sending socket to be tcp as
well.

route[INVITE_RESOLVER] {
xlog("L_DBG", "[R-INVITE-RESOLVER:$ci] Entering INVITE resolver\n");

   route(CHECK_DID);

   # Use main asterisk dispatcher set
   $var(disp_set) = 1;

   # Store diversion reason
   redis_cmd("abn", "SET $fd-div $dir", "r");

   # Trim SIP messages of useless headers
   remove_hf_re("^X-");

   $fs = "tcp:PRIVATE_IP:5080";

   xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] Processing dispatcher set
$var(disp_set)\n");

   if(!ds_select_domain("$var(disp_set)", "4")) {
      # This should only happen if the route set is empty.
      sl_send_reply("503", "Out of Gateways");
      xlog("L_ERR", "[R-INVITE-RESOLVER:$ci] !> "
               "No gateways available!\n");
      exit;
   }

   xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] -> "
             "Selected gateway: $rd:$rp\n");

   t_on_failure("DISPATCHER_ROLLOVER");
   route(INVITE_POSTROUTE);
}

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.

Thanks for your support,


On Tue, Oct 30, 2018 at 9:29 PM Henning Westerholt <hw at kamailio.org> wrote:

> Am Montag, 29. Oktober 2018, 17:27:27 CET schrieb Joan Salvatella:
> > [..]
> >    - *Message Too Long Error:* Since Twilio uses long URIs to define its
> >    resources, the SIP messages being handled by Kamailio are sometimes
> too
> > big and generate a "Message Too Long error". I have been able to
> > temporarily patch this removing unused headers using remove_hf_re and
> > remove_hf but it still fails from time to time. Is there a way to split
> the
> > UDP packet to mitigate this issue? or what other options could be
> > considered?
>
> Hello Joan,
>
> I don't understand the error description completely. Does Kamailio
> complain
> about a to long header field or a too long SIP message?
>
> About the question regarding the options - have you thought about using
> TCP?
>
> Best regards, Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio security assessment - https://skalatan.de/de/assessment
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181101/4fb77d75/attachment.html>