Re: [SR-Users] Very strange reinvite behaviour

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?

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 >