Symptom

Description *********** CUBE is not able to handle the RE-INVITE and in dialog OPTIONS glare ( Race Condition) The moment CUBE initiates to send a RE-INVITE to ITSP, the ITSP already sent OPTIONS. So after few miliseconds of Re-INVITE departure , CUBE receives OPTIONS. CUBE is unable to process this as CUBE hasn't even finished the INVITE transaction which results in CUBE's State machine getting stuck. As a result of which CUBE doesn't pass the 200 OK to the other leg. Finally CUBE discards the entire dialog with a BYE with cause value 102. eg, CUBE -------Re-INVITE -----> ITSP CUBE<--------OPTIONS ------- ITSP Sample errors ************* SE: 0;refresher:none peer refresher:none, flags:140, posted event:E_STSL_INVALID_PEER_EVENT, reason:4 017442: *Aug 10 14:29:33.609:* %SIP-3-BADPAIR: Unexpected event 38 (SIPSPI_EV_CC_OPTIONS_RESP) in state 25 (SIP_STATE_MIDCALL_RECD_SUCCESS) substate 0 (SUBSTATE_NONE)* 017443: *Aug 10 14:30:09.608: //49/2581931580AA/SIP/Info/critical/4096/sipSPIInitiateDisconnect: Initiate call disconnect(102) for incoming call 017445: *Aug 10 14:30:09.608: //49/2581931580AA/SIP/Info/verbose/4096/ccsip_set_release_source_for_peer: ownCallId[49], src[6] 017446: *Aug 10 14:30:09.608: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQSIG: No Inbound Container Created !!! 017447: *Aug 10 14:30:09.608: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQ931: No Inbound Container Created !!! References ********** According to RFC 6337, section 4.2, the UA if cannot process the glare (send 200 OK) should discard the transaction with a 491 Request Pending or 500 Internal server. At any cost the entire dialog should not be terminated with a BYE. Call flow ********** Ip Phone>>> CUCM>>>>CUBE>>>>>ITSP IOS Used: 15.5(3)S6 and 16.3.4 Issue is present on both XE 3.16 and Polaris releases , tested and verified the same. Note: Issue is mostly seen with Middle-East providers.

Conditions

Multiple Re-INVITES and In- dialog OPTIONS Ping from ITSP.

Workaround

Workarounds *********** Currently we have two workarounds in place, 1.Remove the capability of OPTIONS from INVITE, RE-INVITE so that the far-end never sends In-dialog OPTIONS. Voice class sip-profiles 14 request INVITE sip-header Allow-Header modify "OPTIONS," "" request RE-INVITE sip-header Allow-Header modify "OPTIONS," "" Voice service voip Sip Sip-profiles 14 2. Can handled those chatty Re-INVITES in the CUBE. Because if we never send RE-INVITES , the Provider won't be able to reproduce the glare between RE-INVITE and OPTIONS ever. Voice service voip sip midcall-signalling passthru media-change

Further Problem Description