summaryrefslogtreecommitdiff
path: root/res/res_pjsip/presence_xml.c
AgeCommit message (Collapse)Author
2017-08-01res_pjsip_pidf_eyebeam_body_supplement: Correct status presentationSean Bright
This change fixes PIDF content generation when the underlying device state is considered in use. Previously it was incorrectly marked as closed meaning they were offline/unavailable. The code now correctly marks them as open. Additionally: * Generate an XML element for our activity instead of a using a text node. * Consider every extension state other than "unavailable" to be 'open' status. * Update the XML namespaces and structure to reflect those documented in RFC 4480 * Use 'on-the-phone' (defined in RFC 4880) instead of 'busy' as the "in use" activity. This change results in eyeBeam using the appropriate icon for the watched user. This was tested on eyeBeam 1.5.20.2 build 59030 on Windows. ASTERISK-26659 #close Reported by: Abraham Liebsch patches: ASTERISK-26659.diff submitted by snuffy (license 5024) Change-Id: I6e5ad450f91106029fb30517b8c0ea0c2058c810
2017-06-16res_pjsip: New endpoint option "notify_early_inuse_ringing"Alexei Gradinari
This option was added to control whether to notify dialog-info state 'early' or 'confirmed' on Ringing when already INUSE. The value "yes" is useful for some SIP phones (Cisco SPA) to be able to indicate and pick up ringing devices. ASTERISK-26919 #close Change-Id: Ie050bc30023543c7dfb4365c5be3ce58c738c711
2016-01-21res/res_pjsip/presence_xml.c: Add missing 2nd call presence state case.Richard Mudgett
ASTERISK-25712 #close Reported by: Richard Mudgett Change-Id: I70634df24f8c6c3a2c66c45af61d021e4999253f
2015-08-06res_pjsip: Ensure sanitized XML is NULL terminated.Joshua Colp
The ast_sip_sanitize_xml function is used to sanitize a string for placement into XML. This is done by examining an input string and then appending values to an output buffer. The function used by its implementation, strncat, has specific behavior that was not taken into account. If the size of the input string exceeded the available output buffer size it was possible for the sanitization function to write past the output buffer itself causing a crash. The crash would either occur because it was writing into memory it shouldn't be or because the resulting string was not NULL terminated. This change keeps count of how much remaining space is available in the output buffer for text and only allows strncat to use that amount. Since this was exposed by the res_pjsip_pidf_digium_body_supplement module attempting to send a large message the maximum allowed message size has also been increased in it. A unit test has also been added which confirms that the ast_sip_sanitize_xml function is providing NULL terminated output even when the input length exceeds the output buffer size. ASTERISK-25304 #close Change-Id: I743dd9809d3e13d722df1b0509dfe34621398302
2015-04-29res_pjsip: Remove incorrect MODULEINFO from presence_xml.c.Corey Farrell
Remove incorrect MODULEINFO block and unneeded header includes from presence_xml.c. ASTERISK-25027 Reported by: Corey Farrell Change-Id: I977c609ab9d1fe05373027c4138900f6985990eb
2014-07-07res_pjsip_dialog_info_body_generator: Add dialog-info+xml support for presence.Joshua Colp
This module implements dialog-info+xml for the purposes of presence. This means that phones such as Grandstreams can now subscribe to receive presence information for an extension. ASTERISK-21443 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3705/ ........ Merged revisions 418116 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-05-07Improve XML sanitization in NOTIFYs, especially for presence subtypes and ↵Mark Michelson
messages. Embedded carriage return line feed combinations may appear in presence subtypes and messages since they may be derived from user input in an instant messenger client. As such, they need to be properly escaped so that XML parsers do not vomit when the messages are received. ........ Merged revisions 413372 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31Decouple subscription handling from NOTIFY/PUBLISH body generation.Mark Michelson
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