I am working on a VOIP/SIP project. We experience that calls are being "disconnected/dropped" when there is an IP change on the device while an incoming call is RINGING. I.e. the callee has received a SIP INVITE and answered the incoming call with 180 RINGING. Now an IP change happens on the callee device and it sends out SIP REGISTER for the new IP. If then the callee accepts the call with 200 OK on the initial INVITE, the call gets dropped.
If there any RFC describing the "standard" behaviour for the callee device for this specific situation?
Maybe instead of sending a SIP REGISTER, the callee device is supposed to send a re-INVITE?
We are using PJSIP. Bit unclear for me why PJSIP is not making the correct decisions for us here. IP changes within confirmed calls are working fine. PJSIP re-INVITEs and calls do not get dropped.
There are basically two separate mechanisms at work here.
First the registration. If the device's IP address changes it has to re-REGISTER at the registrar in order for new incoming messages, like INVITE requests, to be routed correctly to the device. So the fact that the device sends a REGISTER as soon as its IP address has changed makes perfect sense.
Then the incoming INVITE. In my opinion, the best thing the UAS could have done here is send a final failure response like 480 (Temporarily Unavailable) or 486 (Busy Here). Preferably with a Retry-After header. That way the caller can send a new INVITE after a few seconds, when the device has registered its new IP.
The thing here is that the INVITE creates a dialog; the 180 Ringing has created an early dialog. Part of dialog-creation is advertising the contact address of both participants to each other. This (remote target) address, communicated in the Contact header, is used when sending new requests within that dialog. If a device's IP address changes, the remote target address is bound to change too. For confirmed dialogs the remote target address can be updated by sending a re-INVITE. In the case you're presenting, with an ongoing server transaction, this is not allowed. Since the 180 Ringing response could contain a Contact header with the old IP address, the 200 final response would contain another Contact header value. Changing Contact header values between provisional and final response is not allowed.