[SR-Users] Very strange reinvite behaviour
miconda at gmail.com
Wed Aug 15 16:56:40 CEST 2018
On 15.08.18 16:38, Alex Balashov wrote:
> 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?
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
>> 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).
>> 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
More information about the sr-users