29 Oct
2018
29 Oct
'18
7:27 p.m.
Hello,
We are working on a project that's using a Twilio SIP trunk that diverts
calls from the PSTN to our cluster that is hosting two active-active
Kamailio 5.1 instances that redirect traffic to several Asterisk 15.4
instances.
On this setup we are facing 2 issues:
- *Diversion headers access: *Currently, Kamailio only supports access
to the last diversion header but since we are receiving traffic from Twilio
(it sets the last Diversion header) we are unable to see if the caller was
diverted to our SIP trunk. Is there a workaround for this? Any external
module that would support this use case?
- *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?
Thanks and regards,
30 Oct
30 Oct
12:30 p.m.
On Mon, Oct 29, 2018 at 05:27:27PM +0100, Joan Salvatella wrote:
On this setup we are facing 2 issues:
- *Diversion headers access: *Currently, Kamailio only supports access
to the last diversion header but since we are receiving traffic from Twilio
(it sets the last Diversion header) we are unable to see if the caller was
diverted to our SIP trunk. Is there a workaround for this? Any external
module that would support this use case?
You mean $di points to last Diversion header?
You can access nth header with same name with
$(hdr(name)[n])
See
https://www.kamailio.org/wiki/cookbooks/5.1.x/pseudovariables#hdr_name_-_he…
11:29 p.m.
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
1 Nov
1 Nov
1:18 p.m.
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(a)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
1:29 p.m.
Am Donnerstag, 1. November 2018, 11:18:37 CET schrieb Joan Salvatella:
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.
[..]
$fs = "tcp:PRIVATE_IP:5080";
[..]
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.
> [..]
Hello Joan,
on a first sight it looks fine. Do you get an error from the asterisk side?
Then indeed it would be good to ask on the asterisk user list about that.
If you get also errors in the Kamailio log, we would need more details about
this to continue here.
Best regards,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Kamailio security assessment - https://skalatan.de/de/assessment
7:37 p.m.
Thanks for your help Henning. The error was on Asterisk, now everything is
working like a charm.
On Thu, Nov 1, 2018 at 11:29 AM Henning Westerholt <hw(a)kamailio.org> wrote:
Am Donnerstag, 1. November 2018, 11:18:37 CET schrieb
Joan Salvatella:
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.
[..]
$fs = "tcp:PRIVATE_IP:5080";
[..]
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.
> [..]
Hello Joan,
on a first sight it looks fine. Do you get an error from the asterisk
side?
Then indeed it would be good to ask on the asterisk user list about that.
If you get also errors in the Kamailio log, we would need more details
about
this to continue here.
Best regards,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Kamailio security assessment - https://skalatan.de/de/assessment
2216
days inactive
2219
days old
5 comments
3 participants
participants (3)
-
Daniel Tryba -
Henning Westerholt -
Joan Salvatella