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

[Donat Zenichev]

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>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171119/bc444df6/attachment.html>