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.zenic...@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>
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users