Alright, actually I was able to figure this out and it was basically what you said Nick. I'm actually subscribing to the on_transport_state_change callback, and every time a transport gets connected I hold a reference to it (and release when the transport is shutdown/destroyed). Whenever the IP address/reachability changes, I shutdown all active transports. Subsequent requests use new transports as expected.
Thanks!
Colin
On Fri, Jul 8, 2016 at 7:56 AM Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
Nick,
Thanks for the reply!
I've followed that guide but it doesn't quite seem to work (this is running on 2.5.1).
The issue is that, while the transport is destroyed, the subsequent re-invite never seems to be delivered. PJSIP tries to send the invite but the server never receives it (verified with tcpdumps) which I can only assume is because it's still holding on to the old transport/connection.
Is this something you've seen?
Best,
ColinOn Fri, Jul 8, 2016 at 5:57 AM Nick Dowell <nick@xxxxxxxxxxxxxx> wrote:Hi Colin,
The instructions here should get you started in the right direction:
https://trac.pjsip.org/repos/wiki/IPAddressChange#iphone
In my experience it is not necessary to manually recreate the transports, just call pjsip_transport_shutdown on the active transport and pjsua will create a new one when it needs to send a message. Just one caveat: do not shutdown UDP transports, as they will not be recreated.
Cheers,
Nick
> On 8 Jul 2016, at 06:08, Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
>
> Hey all,
>
> I'm working with an application using TLS transports to talk to a SIP endpoint. The app is running on a mobile device, and I'm trying to destroy and recreate transports in response to reachability change notifications so I can transition between LTE and WiFi for calls.
>
> Currently, I have code that basically runs pjsua_enum_transports(), and calls pjsua_transport_close() on each of them. Then, immediately after, it recreates the transports using the same configuration that was used when the device is configured. Finally, after the transports are recreated, I send re-invites for all active calls.
>
> My problem here is that the re-invites seem to not use the new transports. Rather, for whatever reason, they seem to want to hang up to transports that should already be destroyed, and try sending out through those.
>
> Can anyone point me in the direction of the right way to handle this? The IP address change document on the site focuses only on registrations - however, I'm not using registrations in my app.
>
> Best,
> Colin
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
