15 Aug
2018
15 Aug
'18
1:43 p.m.
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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
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