At a quick glance, it looks like a mixture of strict/loose route processing due to previous hop not setting proper URI.
If R-URI is local address, then it means the previous hop was a strict router. Kamailio tries to switch to loose routing, due to lr parameter, doing the logic of:
- last Route becomes R-URI, overwriting the incoming R-URI (which was local address) and last Route header is deleted - send to top Route header
In strict routing, R-URI is the address of next hop and the last Route is the far end. In loose routing, R-URI is the far end and top Route is next hop. Here seems to be the moment of switching from strict to loose routing.
The UA building the request (or the previous hop) seems to be rather broken, because it adds lr even to the contact address (last Route), even it acts as a strict router.
If you use dialog module in that instance, there is a function to push to R-URI the contact for that side, as saved in the dialog structure. You can do that before calling loose_route(), if R-URI host is your IP (I would avoid using myself on R-URI received from the UA, because if it is messing with the ports/protocols, there can be a mismatch of myself).
Cheers, Daniel
On 15.08.18 00:51, Alex Balashov wrote:
On Tue, Aug 14, 2018 at 11:40:09PM +0200, M S wrote:
It would be good if you can provide the full sip trace that includes the initial INVITE processing of both call legs.
That's not going to be (easily) possible in this case, due to one leg being TLS.
Per SIP v2.0 RFCs (3261, 3665 & 6141), when callee needs to send a sequential request e.g. a re-invite, it should use the Contact header it received in initial INVITE as RURI. Since the RURI and top most Route header(s), all point to kamailio itself, so kamailio sees it as strict routing rather then loose routing, and as a result loop occurs.
Yes. My question was about the inconsistency between the apparent RURI and the message attributes logged.
-- Alex