Handle 2nd INVITE when in early state

[ODCA117]

Ensures 2nd INVITE is handled if in state early.

[sauwming]

As a reference, here's RFC 3261 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.

   A UAS that receives an INVITE on a dialog while an INVITE it had sent
   on that dialog is in progress MUST return a 491 (Request Pending)
   response to the received INVITE.

[wosrediinanatour]

Please use enum instead of magic numbers, e.g. 500 or 491.

[ODCA117]

Fixed the comments

[sauwming]

Please find the attached patch below. Mostly, just to fix the indentation, but also one build failure of missing semicolon.

I have tested it here and it seems to work as expected.
sip_inv_early.txt

[nanangizz]

There is a similar handling in inv_on_state_confirmed(), and it use:

int val = (pj_rand() % 10);

Yes it is unclear whether between 0-10 should be inclusive, but I guess we better apply the same formula in early and confirmed?

[ODCA117]

So changing back to int val = (pj_rand() % 10);?

[sauwming]

It looks like between in the RFC means inclusive such as any response with a status code between 100 and 199 is referred to as a "1xx response".

The correct one should be pj_rand() % 11. But I think % 10 is safer in case that there's any UA that rejects a value of 10.

So yes, please revert it to pj_rand() % 10. Thank you.

[ODCA117]

Done