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

Sun Jul 21 08:35:22 CEST 2019

Can you load debugger module and enable cfgtrace to see the actions
executed in config file for such INVITE - reproduce and send the log
messages. Might be an effect of something done there.

Did I asked if you have IP route from the local IP appearing in
Record-Route to the target IP address? Kamailio has the rule of trying to
reuse first the local ip where the request was received also for sending
out.

On Thu, Jul 18, 2019 at 2:09 PM Leonid Fainshtein <
leonid.fainshtein at xorcom.com> wrote:

> 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
>>
>

-- 
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/20190721/c6eabe4b/attachment.html>