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