We have a VoIP app for the iPhone using PJSIP (2.9). On an ip change the
call continues, but there is no sound. We see the following happening.
- Ip change event.
- PJSIP sends a re-invite.
- The following error occurs: "Unable to create re-INVITE: Invalid
operation (PJ_EINVALIDOP) [status=70013]".
- Another invite succeeds and the call continues, but without any sound.
- By toggling on-hold a new invite is sent.
- Audio restores.
The explanation for no sound after the ip-change event: on the 2nd invite
PJSIP generates new encryption keys, but Asteriks keeps using the old ones
(understandable since it's the same call). So the audio stream can not be
decrypted.
The explanation for generating new encryption keys is (probably) here:
https://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#ga0cb16d0e4d5702e5900e45269a20bb19
"Warning: If the re-INVITE/UPDATE fails, the old media will not be reverted"
So the investigation focuses on why the first re-invite fails with the
PJ_EINVALIDOP error.
The error is thrown a two places during a re-invite:
*
https://github.com/pjsip/pjproject/blob/2.9/pjsip/src/pjsip-ua/sip_inv.c#L2947
with comment 'Must NOT have a pending INVITE transaction'
*
https://github.com/pjsip/pjproject/blob/2.9/pjsip/src/pjsip-ua/sip_inv.c#L1823
with comment 'State MUST be NULL or CONFIRMED'
We could confirm that the state is CONFIRMED, so the re-invite failes
because there is a pending INVITE transaction.
We verified / applied these instructions:
https://trac.pjsip.org/repos/ticket/2041 .
Varying restart_lis_delay does not change the behaviour.
Now we are getting stuck on what to investigate or do to tackle this
problem:
- How can we prevent the PJ_EINVALIDOP error?
- Can we disregard the pending invite and how?
- Can we force using the old encryption keys (or revert the old media)?
- Are there other suggestions to look into?
Notes:
- Without encryption the call (obviously) continues without the audio drop
problem at an ip-change.
- The problem only occurs with a ip-change with (dis)connecting with wifi
<> 4g, not when toggling VPN.
Thanks
Arjen
We have a VoIP app for the iPhone using PJSIP (2.9). On an ip change the
call continues, but there is no sound. We see the following happening.
* Ip change event.
* PJSIP sends a re-invite.
* The following error occurs: "Unable to create re-INVITE: Invalid
operation (PJ_EINVALIDOP) [status=70013]".
* Another invite succeeds and the call continues, but without any sound.
* By toggling on-hold a new invite is sent.
* Audio restores.
The explanation for no sound after the ip-change event: on the 2nd invite
PJSIP generates new encryption keys, but Asteriks keeps using the old ones
(understandable since it's the same call). So the audio stream can not be
decrypted.
The explanation for generating new encryption keys is (probably) here:
https://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__CALL.htm#ga0cb16d0e4d5702e5900e45269a20bb19
"Warning: If the re-INVITE/UPDATE fails, the old media will not be reverted"
So the investigation focuses on why the first re-invite fails with the
PJ_EINVALIDOP error.
The error is thrown a two places during a re-invite:
*
https://github.com/pjsip/pjproject/blob/2.9/pjsip/src/pjsip-ua/sip_inv.c#L2947
with comment 'Must NOT have a pending INVITE transaction'
*
https://github.com/pjsip/pjproject/blob/2.9/pjsip/src/pjsip-ua/sip_inv.c#L1823
with comment 'State MUST be NULL or CONFIRMED'
We could confirm that the state is CONFIRMED, so the re-invite failes
because there is a pending INVITE transaction.
We verified / applied these instructions:
https://trac.pjsip.org/repos/ticket/2041 .
Varying restart_lis_delay does not change the behaviour.
Now we are getting stuck on what to investigate or do to tackle this
problem:
* How can we prevent the PJ_EINVALIDOP error?
* Can we disregard the pending invite and how?
* Can we force using the old encryption keys (or revert the old media)?
* Are there other suggestions to look into?
Notes:
* Without encryption the call (obviously) continues without the audio drop
problem at an ip-change.
* The problem only occurs with a ip-change with (dis)connecting with wifi
<> 4g, not when toggling VPN.
Thanks
Arjen