3 Commits (7a35800551924018bf7edd079e101e7bfe810eb7)

Author	SHA1	Message	Date
Mark Michelson	7a35800551	res_pjsip_pubsub: Add some type safety when generating NOTIFY bodies. ... res_pjsip_pubsub has two separate checks that it makes when a SUBSCRIBE arrives. * It checks that there is a subscription handler for the Event * It checks that there are body generators for the types in the Accept header The problem is, there's nothing that ensures that these two things will actually mesh with each other. For instance, Asterisk will accept a subscription to MWI that accepts pidf+xml bodies. That doesn't make sense. With this commit, we add some type information to the mix. Subscription handlers state they generate data of type X, and body generators state that they consume data of type X. This way, Asterisk doesn't end up in some hilariously mismatched situation like the one in the previous paragraph. ASTERISK-24136 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/3877 Review: https://reviewboard.asterisk.org/r/3878 ........ Merged revisions 423344 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423348 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	f55abe9cf1	Decouple subscription handling from NOTIFY/PUBLISH body generation. ... When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago