Merged revisions 208386 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r208386 | mmichelson | 2009-07-23 14:24:21 -0500 (Thu, 23 Jul 2009) | 17 lines Fix a problem where a 491 response could be sent out of dialog. This generalizes the fix for issue 13849. The initial fix corrected the problem that Asterisk would reply with a 491 if a reinvite were received from an endpoint and we had not yet received an ACK from that endpoint for the initial INVITE it had sent us. This expansion also allows Asterisk to appropriately handle an INVITE with authorization credentials if Asterisk had not received an ACK from the previous transaction in which Asterisk had responded to an unauthorized INVITE with a 407. (closes issue #14239) Reported by: klaus3000 Patches: 14239.patch uploaded by mmichelson (license 60) Tested by: klaus3000 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
parent
dcd6227f6c
commit
88f1d14766
1 changed files with 11 additions and 10 deletions
|
@ -20150,17 +20150,18 @@ static int handle_request_invite(struct sip_pvt *p, struct sip_request *req, int
|
||||||
}
|
}
|
||||||
|
|
||||||
if (!req->ignore && p->pendinginvite) {
|
if (!req->ignore && p->pendinginvite) {
|
||||||
if (!ast_test_flag(&p->flags[0], SIP_OUTGOING) && ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED)) {
|
if (!ast_test_flag(&p->flags[0], SIP_OUTGOING) && (p->invitestate == INV_COMPLETED || p->invitestate == INV_TERMINATED)) {
|
||||||
/* We have received a reINVITE on an incoming call to which we have sent a 200 OK but not yet received
|
/* What do these circumstances mean? We have received an INVITE for an "incoming" dialog for which we
|
||||||
* an ACK. According to RFC 5407, Section 3.1.4, the proper way to handle this race condition is to accept
|
* have sent a final response. We have not yet received an ACK, though (which is why p->pendinginvite is non-zero).
|
||||||
* the reINVITE since we have established a dialog.
|
* We also know that the INVITE is not a retransmission, because otherwise the "ignore" flag would be set.
|
||||||
|
* This means that either we are receiving a reinvite for a terminated dialog, or we are receiving an INVITE with
|
||||||
|
* credentials based on one we challenged earlier.
|
||||||
|
*
|
||||||
|
* The action to take in either case is to treat the INVITE as though it contains an implicit ACK for the previous
|
||||||
|
* transaction. Calling __sip_ack will take care of this by clearing the p->pendinginvite and removing the response
|
||||||
|
* from the previous transaction from the list of outstanding packets.
|
||||||
*/
|
*/
|
||||||
|
__sip_ack(p, p->pendinginvite, 1, 0);
|
||||||
/* Note that this will both clear the pendinginvite flag and cancel the
|
|
||||||
* retransmission of the 200 OK. Basically, we're accepting this reINVITE as both an ACK
|
|
||||||
* and a reINVITE in one request.
|
|
||||||
*/
|
|
||||||
__sip_ack(p, p->lastinvite, 1, 0);
|
|
||||||
} else {
|
} else {
|
||||||
/* We already have a pending invite. Sorry. You are on hold. */
|
/* We already have a pending invite. Sorry. You are on hold. */
|
||||||
p->glareinvite = seqno;
|
p->glareinvite = seqno;
|
||||||
|
|
Loading…
Reference in a new issue