Multiple -Re-invites from UA with incremented Cseq Handling

Question

I have this scenario:

INVITE ----------> 1 Cseq invite
100 <---------- 
180 <---------- 
200 <---------- 
ACK ----------> Call 1 ACK connected
Pause [ 2000ms] 
INVITE ----------> 2Cseq Re-Invite
100 <---------- 
Pause [ 500ms] 
INVITE ----------> 3 Caseq Re-Invite
100 <---------- 
500 <---------- 500 3 cseq response for 3 Re-invite
200 <---------- 200 2 Cseq OK received for 2 nd ReInvite
ACK ----------> Ack of 3 cseq 500 -> here the state in SM is waiting ACK -> connected ACK 
ACK ---------> * Now here Connected ACK>Connected ACK ->Error - This is the issue. *
BYE ----------> 
200 <----------

I read in RFC : 5407

3.1.5. Callee Receives re-INVITE (Established State) While in the Moratorium State (Case 2)

   State  Alice                          Bob  State
          |                                |
          |    ini-INVITE (no offer) F1    |
          |------------------------------->|
     Pre  |             180 F2             |  Pre
          |<-------------------------------|
     Ear  |                                |  Ear
          |    200(ini-INV) w/offer1 F3    |
          |<-------------------------------|
    Mora  |  ACK w/answer1 F4(packet loss) |  Mora
          |-------------------->x          |
     Est  |                                |
          | re-INVITE F6      200 F5(=F3)  |
          |   w/offer2         w/offer1    |
          |-------------     --------------|
          |              \ /               |
          |               X                |
          |              / \               |
          |<------------     ------------->|
          | ACK F7(=F4)      491/500(re-INV) F8|
          |-------------     --------------|
          |              \ /               |
          |               X                |
          |              / \               |
          |<------------     ------------->|
          |        ACK (re-INV) F9         |  Est
          |------------------------------->|
          |                                |

I do See that if we find a Re-invite in Preceding state we will send 500 with same endpoint for this.

My question is :

The above scenarios seems not valid as 2nd Re-Invite with Cseq 3 is sent before any final response .

Should We cater this scenario?If yes , should we Drop Re-Invite and not send 500. As 500 is sent in the RFC Diagram when ACK is sent from UA and is dropped in between?

forty-two forty-two · Accepted Answer · 2016-07-29T15:56:00

It is unclear what the issue is and what the consequences are. However, it is clear that the UAC (the left hand side) is misbehaving. From RFC 3261 section 14.1:

Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.

If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE.

If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE.

But when things go wrong, such as receiving a second INVITE before having responded to the first, the RFC says in section 14.2:

A UAS that receives a second INVITE before it sends the final
response to a first INVITE with a lower CSeq sequence number on the
same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a
randomly chosen value of between 0 and 10 seconds.

So all in all, yes, you should be able to handle the scenario you describe, and the response should be 500.

Multiple -Re-invites from UA with incremented Cseq Handling

2 Answers