Fix a race condition where a canceled call was answered.
authorMark Michelson <mmichelson@digium.com>
Thu, 29 Aug 2013 22:25:16 +0000 (22:25 +0000)
committerMark Michelson <mmichelson@digium.com>
Thu, 29 Aug 2013 22:25:16 +0000 (22:25 +0000)
commitde7ce39187f4cc22ded82a7b10cad1aa7654dfb0
tree11e6e8a261c1960e4a3e8daf3aac001ebb812f1a
parente1cfc18a78195cce9504b61f0aaeb4b61582fa15
Fix a race condition where a canceled call was answered.

RFC 5407 section 3.1.2 details a scenario where a UAC sends
a CANCEL at the same time that a UAS sends a 200 OK for the
INVITE that the UAC is canceling. When this occurs, it is the
role of the UAC to immediately send a BYE to terminate
the call.

This scenario was reproducible by have a Digium phone with two lines
place a call to a second phone that forwarded the call to the second
line on the original phone. The Digium phone, upon realizing that it
was connecting to itself, would attempt to cancel the call. The timing
of this happened to trigger the aforementioned race condition about
80% of the time. Asterisk was not doing its job of sending a BYE
when receiving a 200 OK on a cancelled INVITE. The result was that
the ast_channel structure was destroyed but the underlying SIP
session, as well as the PJSIP inv_session and dialog, were still
alive. Attempting to perform an action such as a transfer, once in
this state, would result in Asterisk crashing.

The circumstances are now detected properly and the session is ended
as recommended in RFC 5407.

(closes issue AST-1209)
reported by John Bigelow
........

Merged revisions 397945 from http://svn.asterisk.org/svn/asterisk/branches/12

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res/res_pjsip_session.c