Lines Matching refs:INVITE
177 * Setting this to <it>true</it> imposes serialization on re-INVITE and makes
178 * the sending of re-INVITEs asynchronous. The sending of re-INVITE is
179 * controlled as follows : If the previous in-DIALOG request was an invite
181 * till an ACK has been sent before admitting the new re-INVITE. If the previous
182 * in-DIALOG transaction was a INVITE ServerTransaction then Dialog waits for
183 * ACK before re-INVITE is allowed to be sent. If a dialog is not ACKed within
260 * transactions. This is not standard behavior per RFC 3261 (INVITE server
337 * CANCEL client transaction is not checked for the existence of the INVITE or
338 * the state of INVITE when you send the CANCEL request. Hence you can CANCEL an
339 * INVITE from a different stack than the INVITE. You can also create a CANCEL
340 * client transaction late and send it out after the INVITE server transaction
348 * Setting this to <it>true</it> imposes serialization on re-INVITE and makes
349 * the sending of re-INVITEs asynchronous. The sending of re-INVITE is
350 * controlled as follows : If the previous in-DIALOG request was an invite
352 * till an ACK has been sent before admitting the new re-INVITE. If the previous
353 * in-DIALOG transaction was a INVITE ServerTransaction then Dialog waits for
354 * ACK before re-INVITE is allowed to be sent. If a dialog is not ACKed within
395 * INVITE client transaction was sent, the stack will place the original INVITE
672 || em.equalsIgnoreCase(Request.INVITE)
