<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Dear Daniel,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Did you have a chance to check the traces?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Leonid<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 9:15 AM Leonid Fainshtein <<a href="mailto:leonid.fainshtein@xorcom.com">leonid.fainshtein@xorcom.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Daniel,<br>
The requested traces can be downloaded by using the link below:<br>
<br>
<a href="http://updates.xorcom.com/~xorcom/kam-tcp-problem.tar.gz" rel="noreferrer" target="_blank">http://updates.xorcom.com/~xorcom/kam-tcp-problem.tar.gz</a><br>
<br>
I don't use the force send socket option and doesn't route out via<br>
dispatcher in this particular call flow.<br>
I found that the problem happens only when the "listen" parameters are<br>
defined in the Kamailio configuration.<br>
Thus the server where I made the tests have the following IPs configured:<br>
<br>
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel<br>
state UP group default qlen 1000<br>
link/ether 00:0c:29:ad:af:e9 brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://192.168.9.103/20" rel="noreferrer" target="_blank">192.168.9.103/20</a> brd 192.168.15.255 scope global dynamic ens32<br>
3: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue<br>
state UP group default qlen 1000<br>
link/ether fe:d8:26:e7:21:dc brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://10.28.80.1/24" rel="noreferrer" target="_blank">10.28.80.1/24</a> scope global lxdbr0<br>
<br>
The request is accepted on 10.28.80.1 and forwarded from 192.168.9.103<br>
<br>
If I define:<br>
listen=udp:<a href="http://10.28.80.1:5060" rel="noreferrer" target="_blank">10.28.80.1:5060</a><br>
listen=tcp:<a href="http://10.28.80.1:5060" rel="noreferrer" target="_blank">10.28.80.1:5060</a><br>
listen=udp:<a href="http://192.168.9.103:5060" rel="noreferrer" target="_blank">192.168.9.103:5060</a><br>
listen=tcp:<a href="http://192.168.9.103:5060" rel="noreferrer" target="_blank">192.168.9.103:5060</a><br>
<br>
Then the problem occurs. Ref. files syslog-bad.log and bad.cap.<br>
If I remove all of the 'listen' parameters then the forwarded INVITE<br>
request is built properly. Ref. files syslog-good.log and good.cap<br>
<br>
Best regards,<br>
Leonid Fainshtein<br>
Xorcom Ltd<br>
<br>
Best regards,<br>
Leonid Fainshtein<br>
Xorcom Ltd<br>
<br>
<br>
On Tue, Jul 9, 2019 at 9:53 AM Daniel-Constantin Mierla<br>
<<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> set debug = 3 in kamailio cfg and reproduce this case. Send here all the<br>
> log messages printed by kamailio from the moment it receives the request<br>
> till it sends it out.<br>
><br>
> Some further questions:<br>
><br>
> - do you use any force send socket option?<br>
> - do you route out via dispatcher? If yes, is the socket attribute set?<br>
><br>
> Cheers,<br>
> Daniel<br>
><br>
> On 08.07.19 21:23, Leonid Fainshtein wrote:<br>
> > Hello,<br>
> > The source address is correct: 192.168.0.31. I see it in tcpdump and<br>
> > also in sngrep.<br>
> ><br>
> > Thank you,<br>
> > Leonid<br>
> ><br>
> > On Mon, Jul 8, 2019 at 9:02 PM Daniel-Constantin Mierla<br>
> > <<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>> wrote:<br>
> >> Hello,<br>
> >><br>
> >> when you look at the network traffic 9e.g., with ngrep, sngrep, ...)<br>
> >> what is shown as source address for outbound leg?<br>
> >><br>
> >> Cheers,<br>
> >> Daniel<br>
> >><br>
> >> On 08.07.19 19:21, Leonid Fainshtein wrote:<br>
> >>> I just found Daniel's response to a similar question (ref.:<br>
> >>> <a href="https://lists.kamailio.org/pipermail/sr-users/2019-February/104853.html" rel="noreferrer" target="_blank">https://lists.kamailio.org/pipermail/sr-users/2019-February/104853.html</a>):<br>
> >>><br>
> >>> "check the routing rules/table of the operating systems, there should be<br>
> >>> some differences between the two servers.<br>
> >>> If you mhomed=1 and an unexpected interface is used for routing out the<br>
> >>> traffic, it means that the operating system has internal routing rules that<br>
> >>> allow going from that interface to the target address."<br>
> >>><br>
> >>> Don't see anything suspicious in my server routing table:<br>
> >>><br>
> >>> default via 192.168.0.1 dev eno1 proto static<br>
> >>> <a href="http://10.159.65.0/24" rel="noreferrer" target="_blank">10.159.65.0/24</a> dev lxdbr0 proto kernel scope link src 10.159.65.1<br>
> >>> <a href="http://172.200.4.0/24" rel="noreferrer" target="_blank">172.200.4.0/24</a> dev eno1 proto kernel scope link src 172.200.4.1<br>
> >>> <a href="http://192.168.0.0/20" rel="noreferrer" target="_blank">192.168.0.0/20</a> dev eno1 proto kernel scope link src 192.168.0.31<br>
> >>><br>
> >>> The request is received on the lxdbr0 interface (10.159.65.1) and sent<br>
> >>> out from the eno1 interface (192.168.0.31).<br>
> >>> I even tried to delete the default route but nothing helped. The<br>
> >>> request is sent out with 10.159.65.1 in the via and Record-Route<br>
> >>> fields...<br>
> >>><br>
> >>> Best regards,<br>
> >>> Leonid<br>
> >>><br>
> >>> On Thu, Jul 4, 2019 at 6:20 PM Leonid Fainshtein<br>
> >>> <<a href="mailto:leonid.fainshtein@xorcom.com" target="_blank">leonid.fainshtein@xorcom.com</a>> wrote:<br>
> >>>> Hi,<br>
> >>>> Kamailio server has two legs that are connected to different networks.<br>
> >>>> I'm using Kamailio v.5.2.3 and the "enable_double_rr" is implicitly set to "1".<br>
> >>>> The leg "A" IP address is 10.159.65.1<br>
> >>>> The leg "B" IP address is 192.168.0.31<br>
> >>>> The call is initiated from 10.159.65.18<br>
> >>>><br>
> >>>> According to the "rr" module documentation, function record_route()<br>
> >>>> should insert two "Record_Route" header fields when a request is<br>
> >>>> accepted on one leg is should go out via the second leg. This works as<br>
> >>>> expected in case of UDP protocol:<br>
> >>>><br>
> >>>> INVITE <a href="http://sip:2000@192.168.6.106:5460" target="_blank">sip:2000@192.168.6.106:5460</a>;transport=UDP SIP/2.0<br>
> >>>> Record-Route: <sip:192.168.0.31;r2=on;lr;did=e2c.a191><br>
> >>>> Record-Route: <sip:10.159.65.1;r2=on;lr;did=e2c.a191><br>
> >>>> Via: SIP/2.0/UDP<br>
> >>>> 192.168.0.31;branch=z9hG4bKcfa5.d64ecbd87d5315b5993c4ccf16f86537.0<br>
> >>>> Via: SIP/2.0/UDP 10.159.65.18:5060;rport=5060;branch=z9hG4bK3a9e9a4d<br>
> >>>><br>
> >>>> But when the TCP protocol is used then the outbound message looks like this:<br>
> >>>><br>
> >>>> INVITE <a href="http://sip:2005@192.168.0.178:35058" target="_blank">sip:2005@192.168.0.178:35058</a>;transport=tcp SIP/2.0<br>
> >>>> Record-Route: <sip:10.159.65.1;transport=tcp;lr;did=bb6.7dc1><br>
> >>>> Via: SIP/2.0/TCP<br>
> >>>> 10.159.65.1;branch=z9hG4bKc85a.14afc3867dd3220826f9b9940f78168f.0;i=3<br>
> >>>> Via: SIP/2.0/TCP 10.159.65.18:5060;rport=58616;branch=z9hG4bK1469331f<br>
> >>>><br>
> >>>> There are two problems there:<br>
> >>>> a) only one Record-Route with leg is inserted<br>
> >>>> b) the added "Via" header field contains the leg "A" IP address<br>
> >>>> instead of expected leg "B" IP address (192.168.0.31). In the LAN<br>
> >>>> trace I see that in reality the message was sent from leg "B".<br>
> >>>><br>
> >>>> Is it a bug?<br>
> >>>><br>
> >>>> Best regards,<br>
> >>>> Leonid Fainshtein<br>
> >>> _______________________________________________<br>
> >>> Kamailio (SER) - Users Mailing List<br>
> >>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
> >>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> >> --<br>
> >> Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
> >> <a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
> >><br>
> --<br>
> Daniel-Constantin Mierla -- <a href="http://www.asipto.com" rel="noreferrer" target="_blank">www.asipto.com</a><br>
> <a href="http://www.twitter.com/miconda" rel="noreferrer" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" rel="noreferrer" target="_blank">www.linkedin.com/in/miconda</a><br>
><br>
</blockquote></div></div>