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(a)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