Summary: | ASTERISK-23557: HEP/PJSIP: Add modules to support integrating Homer with PJSIP | ||
Reporter: | Matt Jordan (mjordan) | Labels: | |
Date Opened: | 2014-03-28 12:59:16 | Date Closed: | 2014-03-28 13:10:34 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_pjsip |
Versions: | 12.0.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ( 0) 12-HEP-PJSIP.patch | |
Description: | This improvement adds the following:
# A new module, res_hep, which implements a generic packet capture agent for the Homer Encapsulation Protocol (HEP) version 3. Note that this code is heavily based on a patch provided by Alexandr Dubovikov; I basically just wrapped it up, added configuration via the configuration framework, and threw in a taskprocessor. # A new module, res_hep_pjsip, which performs packet capturing for the PJSIP SIP stack. This is one of those modules that I think really showcases how nice the new stack is - we're able to add a new module that inserts itself into the stack and forwards the message traffic off to the res_hep module without modifying the core parts of the stack itself. This means a system administrator could load this at will on certain Asterisk systems and - if the capturing isn't needed - unload it and keep the stack 'slim'. A few notes: * This code exists in the following branch: http://svn.asterisk.org/svn/asterisk/team/mjordan/12-hep * The code in the branch also contains a module for RTCP. While that actually *does* send RTCP information over HEP, it does so as a JSON blob, which is not super useful. It's an open question as to what the formatting should be, i.e., a SNOM-esque encoding, RFC 6035, etc. I'm open to suggestions on this, which is why I deferred that functionality for a later review. I'll open another issue for that one when it is further along. Finally, much thanks to Alexandr for his Asterisk patch for this code and for a *lot* of patience waiting for me to port it to 12/trunk. Due to some dithering on my part, this has taken the better part of a year to port forward (I still blame CDRs for the delay). | ||
Comments: |