[SR-Users] re-INVITE on IP Change with Outbound

[Colin Morelli]

Alright,

After better understanding of the SIP spec it looks like even if I can
solve this problem I shouldn't, because Route headers can't change once a
dialog is established (if someone knows a reliable/supported way to make
this happen - that would be great).

However, as long as my client keeps an active TLS connection open to
Kamailio, subsequent messages/responses are delivered over that same
connection. So I'm having the client hold that connection open (and
re-invite in the case that it's closed), and not using outbound on the
invite and now things seem to be working.

Best,
Colin

On Fri, Jul 8, 2016 at 10:32 AM Colin Morelli <colin.morelli at gmail.com>
wrote:

> Hey list,
>
> So I'm using the outbound module to ensure subsequent requests are
> delivered over an active TCP connection established by the mobile client.
> However, now I'm trying to add support for automatically responding to
> network changes (WiFi <-> LTE), and it's creating problems.
>
> Primarily, the issue is that when the device sends a re-INVITE for the
> call, its Route: header includes a flow-token corresponding to its *old* socket
> connection. Because the new request doesn't have the same source IP/port as
> the old connection did Kamailio thinks that the next route hop it needs to
> take is to pass the request over to the connection identified by the flow
> token. So it actually tries to re-open a TCP connection back out to the
> client even though I'm making the re-invite because that old transport is
> no longer valid.
>
> Does anyone have a recommended way of handling this case? I can add
> another header/param to the route header and manually remove it. Before
> loose_routing.
>
> Essentially, on in-dialog INVITE requests I want to ignore the outbound
> token on the originating side but I can't seem to find a way to do that
> without re-writing the header before loose_routing.
>
> Best,
> Colin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160708/4cd68adc/attachment.html>