dect
/
asterisk
Archived
13
0
Fork 0
Code Releases Activity

Add extra protection for reinvite glare scenario. 

Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.

The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.

The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.



git-svn-id: http://svn.digium.com/svn/asterisk/trunk@272090 f38db490-d61c-443f-a65b-d21fe96a405b
This commit is contained in:
mmichelson 2010-06-23 17:08:34 +00:00
parent e60640878f
commit 6322941552
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
channels/chan_sip.c
View File

@ -20508,7 +20508,7 @@ static int handle_request_invite(struct sip_pvt *p, struct sip_request *req, int
p->reqsipoptions = required_profile;
/* Check if this is a loop */
if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->invitestate != INV_TERMINATED && p->invitestate != INV_CONFIRMED)) {
if (ast_test_flag(&p->flags[0], SIP_OUTGOING) && p->owner && (p->invitestate != INV_TERMINATED && p->invitestate != INV_CONFIRMED) && p->owner->_state != AST_STATE_UP) {
/* This is a call to ourself. Send ourselves an error code and stop
processing immediately, as SIP really has no good mechanism for
being able to call yourself */