[SR-Users] Wrong Record-Route and Via header fields when TCP is used

Thu Jul 18 14:09:05 CEST 2019

Yes, I have.

Best regards,
Leonid Fainshtein
Xorcom Ltd

On Thu, Jul 18, 2019 at 9:31 AM Daniel-Constantin Mierla <miconda at 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 at 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 at xorcom.com> wrote:
>>
>>> 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 at 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 at 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 at 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 at 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 at 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 at 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
>>> >
>>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190718/0b420be1/attachment.html>