Fix a specific scenario where ACKs are not matched.

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

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@368629 65c4cc65-6c06-0410-ace0-fbb531ad65f3