On 15.08.18 16:38, Alex Balashov wrote: > Daniel, > > Thank you for this interpretation. I suspected this might be the cause, > but didn't know enough about how non-LR works to merit that speculation. > > Strict routing mostly exists for 2543 compatibility, right? Yes.
The strange thing here is that the UA adds ';lr' to contact address it puts in Route, although it acts (or tries to) as a strict router, so if it is a very old implementation, should not know about adding ';lr' if not present (if present, should be preserved as any URI param). So I would assume someone did a quick/ugly hack for a strict router to 'claim' it is updated for rfc3261, thinking that just adding ';lr' where it is not would be all needed... > > On Wed, Aug 15, 2018 at 12:43:57PM +0200, Daniel-Constantin Mierla wrote: > >> 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 >>> >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio World Conference -- www.kamailioworld.com >> -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users