[SR-Users] Very strange reinvite behaviour

[Daniel-Constantin Mierla]

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