There was a collision of mod_data use on the transaction between using a nat
hook and an session response callback. During state change it was assumed
what was in the mod_data was nothing or the response callback. However, it
was possible for it to also contain a nat hook thus resulting in a bad cast
and a crash.
Added the ability to store multiple data elements in mod_data via a hash table.
In this instance, mod_data now stores a hash table of the two values that can
be retrieved using an associated string key.
(closes issue ASTERISK-22394)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2843/
........
Merged revisions 399990 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During load time in res_pjsip if an error occurred the operation would attempt to rollback all
operations done during load. This is not permitted by PJSIP as it will assert if the operation has
not been done. This fix changes the code so it will only rollback what has been initialized already.
Further changes also prevent res_pjsip and res_pjsip_session from being unloaded. This is due to
limitations within PJSIP itself. The library environment can only be changed to a certain extent
and does not provide the ability, currently, to deinitialize certain required functionality.
(closes issue ASTERISK-22474)
Reported by: Corey Farrell
........
Merged revisions 399624 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:
* The word "Gulp" in dialstrings, functions, and CLI commands is now
"PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
