2014-03-28 18:32:50 +00:00
|
|
|
;
|
|
|
|
|
; res_hep Module configuration for Asterisk
|
|
|
|
|
;
|
|
|
|
|
|
2017-03-14 14:55:06 +00:00
|
|
|
;
|
|
|
|
|
; Note that this configuration file is consumed by res_hep, which is responsible
|
|
|
|
|
; for the HEPv3 protocol manipulation and managing the connection to the Homer
|
|
|
|
|
; capture server. Additional modules provide specific messages to be sent to
|
|
|
|
|
; the Homer server:
|
|
|
|
|
; - res_hep_pjsip: Send SIP messages transmitted/received by the PJSIP stack
|
|
|
|
|
; - res_hep_rtcp: Send RTCP information (all channels)
|
|
|
|
|
;
|
|
|
|
|
|
2014-03-28 18:32:50 +00:00
|
|
|
; All settings are currently set in the general section.
|
|
|
|
|
[general]
|
2016-06-29 20:31:30 +00:00
|
|
|
enabled = no ; Enable/disable forwarding of packets to a
|
2014-03-28 18:32:50 +00:00
|
|
|
; HEP server. Default is "yes".
|
|
|
|
|
capture_address = 192.168.1.1:9061 ; The address of the HEP capture server.
|
2021-10-31 01:04:38 +00:00
|
|
|
capture_password = foo ; If specified, the authorization password
|
2014-03-28 18:32:50 +00:00
|
|
|
; for the HEP server. If not specified, no
|
|
|
|
|
; authorization password will be sent.
|
|
|
|
|
capture_id = 1234 ; A unique integer identifier for this
|
|
|
|
|
; server. This ID will be embedded sent
|
|
|
|
|
; with each packet from this server.
|
2022-11-21 18:53:49 +00:00
|
|
|
;capture_name = asterisk ; A unique string identifier for this
|
|
|
|
|
; server. This ID will be embedded sent
|
|
|
|
|
; with each packet from this server.
|
res_hep: Provide an option to pick the UUID type
At one point in time, it seemed like a good idea to use the Asterisk
channel name as the HEP correlation UUID. In particular, it felt like
this would be a useful identifier to tie PJSIP messages and RTCP
messages together, along with whatever other data we may eventually send
to Homer. This also had the benefit of keeping the correlation UUID
channel technology agnostic.
In practice, it isn't as useful as hoped, for two reasons:
1) The first INVITE request received doesn't have a channel. As a
result, there is always an 'odd message out', leading it to be
potentially uncorrelated in Homer.
2) Other systems sending capture packets (Kamailio) use the SIP Call-ID.
This causes RTCP information to be uncorrelated to the SIP message
traffic seen by those capture nodes.
In order to support both (in case someone is trying to use res_hep_rtcp
with a non-PJSIP channel), this patch adds a new option, uuid_type, with
two valid values - 'call-id' and 'channel'. The uuid_type option is used
by a module to determine the preferred UUID type. When available, that
source of a correlation UUID is used; when not, the more readily available
source is used.
For res_hep_pjsip:
- uuid_type = call-id: the module uses the SIP Call-ID header value
- uuid_type = channel: the module uses the channel name if available,
falling back to SIP Call-ID if not
For res_hep_rtcp:
- uuid_type = call-id: the module uses the SIP Call-ID header if the
channel type is PJSIP and we have a channel,
falling back to the Stasis event provided
channel name if not
- uuid_type = channel: the module uses the channel name
ASTERISK-25352 #close
Change-Id: Ide67e59a52d9c806e3cc0a797ea1a4b88a00122c
2016-05-12 01:17:15 +00:00
|
|
|
uuid_type = call-id ; Specify the preferred source for the Homer
|
|
|
|
|
; correlation UUID. Valid options are:
|
2022-11-28 20:05:21 +00:00
|
|
|
; - 'call-id' for the PJSIP
|
res_hep: Provide an option to pick the UUID type
At one point in time, it seemed like a good idea to use the Asterisk
channel name as the HEP correlation UUID. In particular, it felt like
this would be a useful identifier to tie PJSIP messages and RTCP
messages together, along with whatever other data we may eventually send
to Homer. This also had the benefit of keeping the correlation UUID
channel technology agnostic.
In practice, it isn't as useful as hoped, for two reasons:
1) The first INVITE request received doesn't have a channel. As a
result, there is always an 'odd message out', leading it to be
potentially uncorrelated in Homer.
2) Other systems sending capture packets (Kamailio) use the SIP Call-ID.
This causes RTCP information to be uncorrelated to the SIP message
traffic seen by those capture nodes.
In order to support both (in case someone is trying to use res_hep_rtcp
with a non-PJSIP channel), this patch adds a new option, uuid_type, with
two valid values - 'call-id' and 'channel'. The uuid_type option is used
by a module to determine the preferred UUID type. When available, that
source of a correlation UUID is used; when not, the more readily available
source is used.
For res_hep_pjsip:
- uuid_type = call-id: the module uses the SIP Call-ID header value
- uuid_type = channel: the module uses the channel name if available,
falling back to SIP Call-ID if not
For res_hep_rtcp:
- uuid_type = call-id: the module uses the SIP Call-ID header if the
channel type is PJSIP and we have a channel,
falling back to the Stasis event provided
channel name if not
- uuid_type = channel: the module uses the channel name
ASTERISK-25352 #close
Change-Id: Ide67e59a52d9c806e3cc0a797ea1a4b88a00122c
2016-05-12 01:17:15 +00:00
|
|
|
; - 'channel' for the Asterisk channel name
|
2017-05-09 10:25:29 +00:00
|
|
|
; Note: If 'call-id' is specified but the
|
2022-11-28 20:05:21 +00:00
|
|
|
; channel is not PJSIP then the Asterisk
|
|
|
|
|
; channel name will be used instead.
|
