........
r368629 | mmichelson | 2012-06-06 14:18:20 -0500 (Wed, 06 Jun 2012) | 31 lines
Fix a specific scenario where ACKs are not matched.
If a dialog-starting INVITE contains a to-tag, then Asterisk
will respond with a 481. In this case, the resulting incoming
ACK would not be matched, so Asterisk would continue retransmitting
the 481 until the transaction times out.
There were two issues. Asterisk, upon creating a sip_pvt would generate
a local tag. However, when the time came to transmit the 481, since there
was a to-tag in the INVITE, Asterisk would place this original to-tag
in the 481 response. When the ACK came in, Asterisk would attempt to
match the to-tag in the ACK to the generated local tag. Unfortunately,
Asterisk never actually transmitted a response with the generated local
tag, so the to-tag in the ACK would not match.
The other problem was that when the 481 was sent, nothing was set
on the sip_pvt to indicate what CSeq is expected in the ACK.
To fix the first problem, we zero out the to-tag seen in the incoming
INVITE. This way, Asterisk, when time to send a response, will send
its generated local tag instead.
To fix the second problem, we set the sip_pvt's pendinginvite to the
CSeq of the INVITE when we send a 481.
(closes issue ASTERISK-19892)
Reported by Mark Michelson
........
Merged revisions 368625 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
r368645 | rmudgett | 2012-06-06 16:32:09 -0500 (Wed, 06 Jun 2012) | 17 lines
Fix POTS flash hook to orignate a second call deadlock.
A deadlock can occur when a POTS phone tries to flash hook to originate a
second call for 3-way or transfer. If another process is scanning the
channels container when the POTS line flash hooks then a deadlock will
occur.
* Release the channel and private locks when creating a new channel as a
result of a flash hook.
(closes issue ASTERISK-19842)
Reported by: rmudgett
Tested by: rmudgett
........
Merged revisions 368644 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368629,368645 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10-digiumphones@368782
65c4cc65-6c06-0410-ace0-
fbb531ad65f3
ast_log(LOG_WARNING, "Unable to allocate three-way subchannel\n");
goto winkflashdone;
}
- /* Make new channel */
+
+ /*
+ * Make new channel
+ *
+ * We cannot hold the p or ast locks while creating a new
+ * channel.
+ */
+ ast_mutex_unlock(&p->lock);
+ ast_channel_unlock(ast);
chan = dahdi_new(p, AST_STATE_RESERVED, 0, SUB_THREEWAY, 0, NULL);
+ ast_channel_lock(ast);
+ ast_mutex_lock(&p->lock);
if (p->dahditrcallerid) {
if (!p->origcid_num)
p->origcid_num = ast_strdup(p->cid_num);
if (!p->initreq.headers && req->has_to_tag) {
/* If this is a first request and it got a to-tag, it is not for us */
if (!req->ignore && req->method == SIP_INVITE) {
+ /* We will be subversive here. By blanking out the to-tag of the request,
+ * it will cause us to attach our own generated to-tag instead. This way,
+ * when we receive an ACK, the ACK will contain the to-tag we generated,
+ * resulting in a proper to-tag match.
+ */
+ char *to_header = (char *) sip_get_header(req, "To");
+ char *tag = strstr(to_header, ";tag=");
+ *tag = '\0';
+ p->pendinginvite = p->icseq;
transmit_response_reliable(p, "481 Call/Transaction Does Not Exist", req);
/* Will cease to exist after ACK */
return res;
ast_log(LOG_WARNING, "Unable to allocate three-way subchannel\n");
goto winkflashdone;
}
- /* Make new channel */
+
+ /*
+ * Make new channel
+ *
+ * We cannot hold the p or ast locks while creating a new
+ * channel.
+ */
+ analog_unlock_private(p);
+ ast_channel_unlock(ast);
chan = analog_new_ast_channel(p, AST_STATE_RESERVED, 0, ANALOG_SUB_THREEWAY, NULL);
+ ast_channel_lock(ast);
+ analog_lock_private(p);
if (!chan) {
ast_log(LOG_WARNING,
"Cannot allocate new call structure on channel %d\n",
projects / thirdparty / asterisk.git / commitdiff
