called twice rtpengine_manage trigger looped media

[sergey-safarov]

We have a carrier that ignores the Record-Route and Route headers negotiated at the start of the dialog and sends a ReINVITE to another Kamailio server. Second Kamailio calls rtpengine_manage and then relay ReINVITE message according to Route header to the first Kamailio. The first Kamailio calls rtpengine_manage again and this triggers high CPU load on the server and pike of network traffic via loopback interface. Screenshot attached

And in the RTPEngine logs we can see in the rtpengine.log Here you will find

safarov@nout:~$ grep offer rtpengine.log
INFO: [3ebd87f3-f13d-443d-b8c1-5bcb3c2560d4]: [control] Received command 'offer' from [xxxx:xxxx:xxxx:xxxx::7]:49476
INFO: [3ebd87f3-f13d-443d-b8c1-5bcb3c2560d4]: [control] Replying to 'offer' from [xxxx:xxxx:xxxx:xxxx::7]:49476 (elapsed time 0.000201 sec)
INFO: [3ebd87f3-f13d-443d-b8c1-5bcb3c2560d4]: [control] Received command 'offer' from [xxxx:xxxx:xxxx:xxxx::6]:40415
INFO: [3ebd87f3-f13d-443d-b8c1-5bcb3c2560d4]: [control] Replying to 'offer' from [xxxx:xxxx:xxxx:xxxx::6]:40415 (elapsed time 0.000281 sec)

We will try make a workarround for not expected behoifour from the carrier equipemnt, but will be fine to avoid create loop on the RTPengine. I think will be fine to return error if rtpengine_manage received own IP in the peer SDP.

[sergey-safarov]

not-expected-reinvite.pcap.gz

[zenichev]

@sergey-safarov hm, good catch, let me see, what we can do here.

[zenichev]

@sergey-safarov you could probably try to use the loop protect flag, which prevents processing of SDPs generated previously by rtpengine. Would that work for you?

Check the doc: https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html

[sergey-safarov]

For me looks like it is an appropriate change in the Kamailio config to avoid this case. But cannot test it now because another carrier disabled the "timer" feature and ReINVITE does not send more. I will close it at solved.