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@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