[SR-Users] Source socket/port for in-dialog requests

Wed Nov 29 15:56:40 CET 2017

Answer was found.

The problem was in double rewriting of the remote uri.

First, in natdetect route - add_contact_alias() was used:
-Adds ;alias=ip:port parameter to contact URI containing received ip:port
if contact uri ip:port does not match received ip:port.

Second, fix_nated_contact was used for all invite requests (no matter they
are loose routed or not):
-Rewrites Contact HF to contain request's source address:port.

So that made us a problem, when BYE requests contained RURI different from
contact headers of incoming INVITEs from uplink.

Well, conclusion is - be careful not to make such obvious mistakes.

2017-11-19 0:38 GMT+02:00 Donat Zenichev <donat.zenichev at gmail.com>:

> Hi community.
> My apologies for so frequent appealing to you.
>
> I'm trying to solve problem with ending of sessions.
> The problem consists of no 200 OK coming from uplink on our BYE requests.
>
> Topology.
> First leg:
> Webrtc client <-wss-> kamailio <-sip tcp-> asterisk routing server
>
> Second leg:
> Uplink <-sip tcp-> kamailio <-sip tcp-> asterisk routing server
>
> The problem appears only in case when dialog was ended by webrtc client.
> The first leg (dialog) of the call ends nice, without any hints on problem.
> But the second leg (with uplink) has problem with no 200 OK (coming from
> uplink) on BYE request coming from asterisk.
>
> Handshake between asterisk server and uplink establishes properly.
> It looks like:
>
> uplink.domain.com:5060 -> INVITE tcp -> our.kamailio.server:5060 ->
> INVITE tcp -> our.asterisk.server:5060
> .
> uplink.domain.com:5060 <- 100 trying tcp <- our.kamailio.server:5060
> .
> uplink.domain.com:5060 <- 180 ringing tcp <- our.kamailio.server:5060 <-
> 180 ringing tcp <- our.asterisk.server:5060
> .
> uplink.domain.com:5060 <- 200 OK tcp <- our.kamailio.server:5060 <- 200
> OK tcp <- our.asterisk.server:5060
> .
> uplink.domain.com:5060 -> ACK tcp -> our.kamailio.server:5060 -> ACK tcp
> -> our.asterisk.server:5060
> .
> uplink.domain.com <-media stream-> rtpengine <-media stream->
> our.asterisk.server
> .
> Here kamailio starts to use random source port for relaying in-dialog BYE
> uplink.domain.com:5060 <- BYE tcp <- our.kamailio.server:45355 <- BYE tcp
> <- our.asterisk.server:5060
> .
> And here the leg with uplink is expected to end with 200 OK (coming from
> uplink proxy).
> But uplink doesn't answer at all.
>
> We requested a tcpdump from uplink to see how packets are forwared from
> their side. And I saw that that 200 OK tries to be sent within first tcp
> session - to 5060 port of kamailio server.
> But sngrep on our side shows nothing, nothing appears in kamailio log, so
> 200 OK can't reach the 5060 socket because of some transport problem I
> think.
> Top via hf of our BYE request, contains kamailio record =
> uplink.domain.com:5060
>
> My main thought on this count is to suppress using of random source ports
> for in-dialog requests, this behaviour looks irrelevant.
>
> We have turned on mhomed parameter (mhomed=1). And cookbook says:
> "Set the server to try to locate outbound interface on multihomed host.
> This parameter affects the selection of the outgoing socket for forwarding
> requests."
>
> But, there is a big but - we can not turn of this parameter for this
> moment, because routing script made with using of this one.
>
> Kamilio works on AWS EC2 platform. It has following IP address schema:
> private address atouched to container -> public address assinged to this
> private address (so this is standard ip address schema for AWS containers).
> For this example private address will be: 10.0.0.1
> and public address will be: 100.0.0.1
>
> Configuration - main parameters (all values are changed for an example):
> advertised_address=our.kamailio.server
> advertised_port=5060
>
> alias=our.kamailio.server
> alias=our.kamailio.server:5060
>
> alias=100.0.0.1
> alias=100.0.0.1:5060
>
> alias=10.0.0.1
> alias=10.0.0.1:5060
>
> auto_aliases=no
>
> port=5060
>
> listen=100.0.0.1
> listen=10.0.0.1
>
> listen=tcp:100.0.0.1:5060
> listen=tcp:10.0.0.1:5060
>
> mhomed=1
>
> fork=yes
> fork_delay=5000
> children=6
>
> tcp_connection_lifetime=3604
> tcp_accept_no_cl=yes
> tcp_connect_timeout=5
> tcp_send_timeout=5
> tcp_rd_buf_size=16384
> tcp_keepalive=yes
> tcp_crlf_ping=yes
> tcp_keepcnt=3
> tcp_keepidle=30
> tcp_keepintvl=15
> tcp_max_connections=4096
>
> One of the solutions to this problem was to add following inside the
> relaying route block:
>
> $fs = "tcp:" + "10.0.0.1" + ":5060";
>
> if (!t_relay()) {
>     sl_reply_error();
> }
>
>
> But it seems to me it's not a smart solution.
>
>
> --
> --
> BR, Donat Zenichev
> Wnet VoIP team
> Tel Ukraine:  +380(44) 5-900-800
> Tel USA: +164(67) 8-174-17
> https://w-net.us/ <http://wnet.ua>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_-7967873163798294733_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

-- 
-- 
BR, Donat Zenichev
Wnet VoIP team
Tel Ukraine:  +380(44) 5-900-800
Tel USA: +164(67) 8-174-17
https://w-net.us/ <http://wnet.ua>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171129/1004a0ab/attachment.html>