Hi all, I'm facing a problem dealing with network change on the client that communicates with FreeSwitch server. Before: X1:Y1 <-> FreeSwitchIP:5060 After: X2:Y2 <-> FreeSwitchIP:5060 When the call is established, i.e: initial INVITE answered, everything work fine to me with the use of re-INVITE following rfc3261 on modifying an existing dialog: FreeSwitch recognize my client changed to X2:Y2 and later BYE routed properly. But when the call is NOT established and in early-media state, I have to use the UPDATE and the result is not as expected. Although FreeSwitch also recognized my client changed to X2:Y2 but only for later transactions and BYE, the 200 OK of the initial INVITE is still routed to X1:Y1. That does not meet my requirement as the expectation is X1:Y1 not usable in the middle of the call. I understand that UPDATE may not be suitable for such cases since it's a different transaction from the initial INVITE, also not even the problem with FreeSwitch alone, but can you help to point me out on this? Wanted to know if there's any rfc suitable. A workaround is to create a complete new call with SIP Replaces header at X2:Y2 containing the dialog info of old call at X1:Y1, resulting in FreeSwitch having a very nice replacement, but it's a bit costly to me in another story. Any help would be appreciated. rgds, Loi Dang Thanh Phone : +84. 774.735.448 Email : loi.dangthanh@gmail.com