]> git.ipfire.org Git - thirdparty/asterisk.git/commit
Multiple revisions 368629,368645
authorJason Parker <jparker@digium.com>
Mon, 11 Jun 2012 21:54:53 +0000 (21:54 +0000)
committerJason Parker <jparker@digium.com>
Mon, 11 Jun 2012 21:54:53 +0000 (21:54 +0000)
commit0d52410a6dfc4ec987caba03a1c263ba21cb0f65
tree5fe9fa79db72ed1a9ca4d4883c61b11e67707b59
parentf3f2ac35f45b8d81e9dd8e468fb792523c4d982d
Multiple revisions 368629,368645

........
  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
channels/chan_dahdi.c
channels/chan_sip.c
channels/sig_analog.c