Two simultaneous calls to a SIP-phone

We make a call at the same time to the SIP softphone (3CX). If you make calls almost simultaneously, the SIP-phone just does not respond to the second call, if you do a little bit at the same time, then everything works less or less, although not always. Someone on the way sometimes considers these calls as one call. In the WireShark logs you can see that the second Invite is flying, but the SIP phone does not respond to it. More interesting, instead of 3CX, we launch another softphone X-lite and also make two simultaneous calls to it. In this case, one call looks like this:

  • INVITE ->
  • <- Trying
  • <- Ringing
  • <- 200 OK
  • ACK ->

Second, with reverse Invite:

  • INVITE ->
  • <- Trying
  • <- Ringing
  • <- 200 OK
  • ACK ->
  • <- INVITE - Reverse invite with same CALL-ID
  • Trying ->
  • 200 OK ->
  • <- ACK

Apparently the reverse invite is used just to divide and process two simultaneous incoming calls. Maybe someone knows what this method is and in what cases it should be used?

Re-INVITE is used for lots of things but not “divide calls”. It is unusual for a phone to initiate a re-INVITE, especially so for a one given away as a loss leader.

At the moment you seem to have buggy soft phones, but to fully analyse this we would need the protocol traces, from Asterisk, of the complete pairs of calls.

Also, the way I have read this, these are the outgoing legs from Asterisk, as you say “to the SIP” phone, but Asterisk is much more likely to initiate a re-INVITE than a soft phone, which suggests an incoming leg.

Finally, you need to do more reading on how SIP calls normally work, as you clearly don’t understand re-INVITEs.

Thanks for your reply,
I really did not encounter reverse invites, it is even more strange that they come from a SIP-phone.
Here’s what it looks like:
SIP1
It is interesting that in this case everything works.

As said above, it looks like bugs in the softphones.
If a softphone does not respond to the message coming just after another message (but responds if it comes with a delay), it means that SIP-related code is running in a synchronous (blocking) mode, and the phone is not designed well for parallel call processing.

It any case, the issue is not related to Asterisk.

Thanks for your reply.
In the first case, I think this is really a sip-phone error. But the second is not sure. I came across a problem described by me here: Asterisk does not send CANCEL when calling a group
and suggested that this is a possible solution to this problem.