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
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 q
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
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),
It would be good if you can provide the full sip trace that includes the
initial INVITE processing of both call legs.
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. Sinc
Yes, there is a typoed brace that is in reality located elsewhere. That
is not the salient feature of this scenario. The if blocks are separate,
as you'd expect them to be.
loose_route() will parse the Route headers and remove the local ones,
and may set the destination set appropriately, but will
The problem is caused by the second IF in your script block. You called
loose_route which parses the Route headers and change RURI. So move the
code block above second IF. Also you have already filtered method for
INVITE so no need to apply method filter again in last IF.
Hope this helps.
Thank y
One curiosity is that the reinvite does not appear to have the Via from
the UAC that sent the initial invite. But certainly that would not cause
this behaviour?
On Tue, Aug 14, 2018 at 12:52:50PM -0400, Alex Balashov wrote:
> Another aspect of this mystery:
>
> Here is the route set in the rein
Another aspect of this mystery:
Here is the route set in the reinvite:
Route:
Route:
Route:
The expectation would be that Kamailio would strip off its two Routes
and then relay this request to 3.3.3.3:5060, even if the RURI says to
relay the request to itself.
But that's not w
Hi,
We have a scenario like this:
ITSP -> Kamailio -> Endpoint
(UDP)(TLS)
So, TLS is only being used on the last hop, and the upstream interaction
with the ITSP is plain-old UDP.
Kamailio has the following listeners:
listen=udp:1.1.1.1:5060
listen=udp:1.1.1
10 matches
Mail list logo
