I'm writing asterisk agi script for 1.8 asterisk. Before dial, I want to check if desired SIP channel is available.
But I cant find a way to check if SIP channel is online using Asterisk::AGI
trying $AGI->channel_status('SIP/1001');
but it always returns -1
I was thinking to use AMI, but it doesn't work from AGI script (only in debug asterisk -vvvvc)
You can get result of function SIP_PEER or function CHANNEL
pro-sip*CLI> core show function SIPPEER
-= Info about function 'SIPPEER' =-
[Synopsis]
Gets SIP peer information.
[Description]
Not available
[Syntax]
SIPPEER(peername[,item])
[Arguments]
item
ip - (default) The ip address.
port - The port number.
mailbox - The configured mailbox.
context - The configured context.
expire - The epoch time of the next expire.
dynamic - Is it dynamic? (yes/no).
callerid_name - The configured Caller ID name.
callerid_num - The configured Caller ID number.
callgroup - The configured Callgroup.
pickupgroup - The configured Pickupgroup.
codecs - The configured codecs.
status - Status (if qualify=yes).
regexten - Registration extension.
limit - Call limit (call-limit).
busylevel - Configured call level for signalling busy.
curcalls - Current amount of calls. Only available if call-limit
is set.
language - Default language for peer.
accountcode - Account code for this peer.
useragent - Current user agent id for peer.
maxforwards - The value used for SIP loop prevention in outbound
requests
chanvar[name] - A channel variable configured with setvar for this
peer.
codec[x] - Preferred codec index number <x> (beginning with
zero).
[See Also]
Not available
pro-sip*CLI>
pro-sip*CLI> core show function CHANNEL
-= Info about function 'CHANNEL' =-
[Synopsis]
Gets/sets various pieces of information about the channel.
[Description]
Gets/sets various pieces of information about the channel, additional <item>
may be available from the channel driver; see its documentation for details.
Any <item> requested that is not available on the current channel will return
an empty string.
[Syntax]
CHANNEL(item)
[Arguments]
item
Standard items (provided by all channel technologies) are:
amaflags - R/W the Automatic Message Accounting (AMA) flags on the
channel. When read from a channel, the integer value will always be
returned. When written to a channel, both the string format or integer
value is accepted.
1 - 'OMIT'
2 - 'BILLING'
3 - 'DOCUMENTATION'
accountcode - R/W the channel's account code.
audioreadformat - R/O format currently being read.
audionativeformat - R/O format used natively for audio.
audiowriteformat - R/O format currently being written.
callgroup - R/W call groups for call pickup.
channeltype - R/O technology used for channel.
checkhangup - R/O Whether the channel is hanging up (1/0)
language - R/W language for sounds played.
musicclass - R/W class (from musiconhold.conf) for hold music.
name - The name of the channel
parkinglot - R/W parkinglot for parking.
rxgain - R/W set rxgain level on channel drivers that support it.
secure_bridge_signaling - Whether or not channels bridged to this
channel require secure signaling
secure_bridge_media - Whether or not channels bridged to this channel
require secure media
state - R/O state for channel
tonezone - R/W zone for indications played
transfercapability - R/W ISDN Transfer Capability, one of:
SPEECH
DIGITAL
RESTRICTED_DIGITAL
3K1AUDIO
DIGITAL_W_TONES
VIDEO
txgain - R/W set txgain level on channel drivers that support it.
videonativeformat - R/O format used natively for video
trace - R/W whether or not context tracing is enabled, only available
*if CHANNEL_TRACE is defined*.
*chan_sip* provides the following additional options:
peerip - R/O Get the IP address of the peer.
recvip - R/O Get the source IP address of the peer.
from - R/O Get the URI from the From: header.
uri - R/O Get the URI from the Contact: header.
useragent - R/O Get the useragent.
peername - R/O Get the name of the peer.
t38passthrough - R/O '1' if T38 is offered or enabled in this channel,
otherwise '0'
rtpqos - R/O Get QOS information about the RTP stream
This option takes two additional arguments:
Argument 1:
'audio' Get data about the audio stream
'video' Get data about the video stream
'text' Get data about the text stream
Argument 2:
'local_ssrc' Local SSRC (stream ID)
'local_lostpackets' Local lost packets
'local_jitter' Local calculated jitter
'local_maxjitter' Local calculated jitter (maximum)
'local_minjitter' Local calculated jitter (minimum)
'local_normdevjitter'Local calculated jitter (normal
deviation)
'local_stdevjitter' Local calculated jitter (standard
deviation)
'local_count' Number of received packets
'remote_ssrc' Remote SSRC (stream ID)
'remote_lostpackets'Remote lost packets
'remote_jitter' Remote reported jitter
'remote_maxjitter' Remote calculated jitter (maximum)
'remote_minjitter' Remote calculated jitter (minimum)
'remote_normdevjitter'Remote calculated jitter (normal
deviation)
'remote_stdevjitter'Remote calculated jitter (standard
deviation)
'remote_count' Number of transmitted packets
'rtt' Round trip time
'maxrtt' Round trip time (maximum)
'minrtt' Round trip time (minimum)
'normdevrtt' Round trip time (normal deviation)
'stdevrtt' Round trip time (standard deviation)
'all' All statistics (in a form suited to
logging, but not for parsing)
rtpdest - R/O Get remote RTP destination information.
This option takes one additional argument:
Argument 1:
'audio' Get audio destination
'video' Get video destination
'text' Get text destination
Defaults to 'audio' if unspecified.
rtpsource - R/O Get source RTP destination information.
This option takes one additional argument:
Argument 1:
'audio' Get audio destination
'video' Get video destination
'text' Get text destination
Defaults to 'audio' if unspecified.
*chan_iax2* provides the following additional options:
osptoken - R/O Get the peer's osptoken.
peerip - R/O Get the peer's ip address.
peername - R/O Get the peer's username.
secure_signaling - R/O Get the if the IAX channel is secured.
secure_media - R/O Get the if the IAX channel is secured.
*chan_dahdi* provides the following additional options:
dahdi_channel - R/O DAHDI channel related to this channel.
dahdi_span - R/O DAHDI span related to this channel.
dahdi_type - R/O DAHDI channel type, one of:
analog
mfc/r2
pri
pseudo
ss7
keypad_digits - R/O PRI Keypad digits that came in with the SETUP
message.
reversecharge - R/O PRI Reverse Charging Indication, one of:
-1 - None
1 - Reverse Charging Requested
no_media_path - R/O PRI Nonzero if the channel has no B channel.
The channel is either on hold or a call waiting call.
buffers - W/O Change the channel's buffer policy (for the current
call only)
This option takes two arguments:
Number of buffers,
Buffer policy being one of:
'full'
'immediate'
'half'
echocan_mode - W/O Change the configuration of the active echo
canceller on the channel (if any), for the current call only.
Possible values are:
'on' Normal mode (the echo canceller is actually reinitalized)
'off' Disabled
'fax' FAX/data mode (NLP disabled if possible, otherwise co
mpletely disabled)
'voice' Voice mode (returns from FAX mode, reverting the changes
that were made)
[See Also]
Not available
Based on answer of arheops this is the working AGI to test a SIP channel status:
$AGI->exec("EXEC Set(TESTVAR=\${SIPPEER(8880101,status)})");
my $testvar = $AGI->get_variable('TESTVAR');
$AGI->verbose("testvar $testvar");
Cli log:
AGI.agi: testvar OK (170 ms)
of course qualify=yes should be set for the peer or globally
Related
We're using DPDK (version 20.08 on ubuntu 20.04, c++ application) to receive UDP packets with a high throughput (>2 Mpps). We use a Mellanox ConnectX-5 NIC (and a Mellanox ConnectX-3 in an older system, would be great if the solution worked there aswell).
Contrary, since we only need to send a few configuration messages, we send messages through the default network stack. This way, we can use lots of readily available tools to send configuration messages; however, since all the received data is consumed by DPDK, these tools do not get back any messages.
The most prominent issue arises with ARP negotiation: the host tries to resolve addresses, the clients also do respond properly, however, these responses are all consumed by DPDK such that the host cannot resolve the addresses and refuses to send the actual UDP packets.
Our idea would be to filter out the high throughput packets on our application and somehow "forward" everything else (e.g. ARP responses) to the default network stack. Does DPDK have a built-in solution for that? I unfortunatelly coulnd't find anything in the examples.
I've recently heard about the packet function which allows to inject packets into SOCK_DGRAM sockets which may be a possible solution. I also couldn't find a sample implementation for our use-case, though. Any help is greatly appreciated.
Theoretically, if the NIC in question supports the embedded switch feature, it should be possible to intercept the packets of interest in the hardware and redirect them to a virtual function (VF) associated with the physical function (PF), with the PF itself receiving everything else.
The user configures SR-IOV feature on the NIC / host as well as virtualisation support;
For a given NIC PF, the user adds a VF and binds it to the corresponding Linux driver;
The DPDK application is run with the PF ethdev and a representor ethdev for the VF;
To handle the packets in question, the application adds the corresponding flow rules.
The PF (ethdev 0) and the VF representor (ethdev 1) have to be explicitly specified by the corresponding EAL argument in the application: -a [pci:dbdf],representor=vf0.
As for the flow rules, there should be a pair of such.
The first rule's components are as follows:
Attribute transfer (demands that matching packets be handled in the embedded switch);
Pattern item REPRESENTED_PORT with port_id = 0 (instructs the NIC to intercept packets coming to the embedded switch from the network port represented by the PF ethdev);
Pattern items matching on network headers (these provide narrower match criteria);
Action REPRESENTED_PORT with port_id = 1 (redirects packets to the VF).
In the second rule, item REPRESENTED_PORT has port_id = 1, and action REPRESENTED_PORT has port_id = 0 (that is, this rule is inverse). Everything else should remain the same.
It is important to note that some drivers do not support item REPRESENTED_PORT at the moment. Instead, they expect that the rules be added via the corresponding ethdevs. This way, for the provided example: the first rule goes to ethdev 0, the second one goes to ethdev 1.
As per the OP update, the adapter in question might indeed support the embedded switch feature. However, as noted above, item REPRESENTED_PORT might not be supported. The rules should be inserted via specific ethdevs. Also, one more attribute, ingress, might need to be specified.
In order to check whether this scheme works, one should be able to deploy a VF (as described above) and run testpmd with the aforementioned EAL argument. In the command line of the application, the two flow rules can be tested as follows:
flow create 0 ingress transfer pattern eth type is 0x0806 / end actions represented_port ethdev_port_id 1 / end
flow create 1 ingress transfer pattern eth type is 0x0806 / end actions represented_port ethdev_port_id 0 / end
Once done, that should pass ARP packets to the VF (thus, to the network interface) in question. The rest of packets should be seen by testpmd in active forwarding mode (start command).
NOTE: it is recommended to switch to the most recent DPDK release.
For the current use case, the best option is to make use of DPDK TAP PMD (which is part of LINUX DPDK). You can use Software or Hardware to filter the specific packets then sent it desired TAP interface.
A simple example to demonstrate the same would be making use DPDK skeleton example.
build the DPDK example via cd [root folder]/example/skeleton; make static
pass the desired Physical DPDK PMD NIC using DPDK eal options ./build/basicfwd -l 1 -w [pcie id of DPDK NIC] --vdev=net_tap0;iface=dpdkTap
In second terminal execute ifconfig dpdkTap 0.0.0.0 promisc up
Use tpcudmp to capture Ingress and Egress packets using tcpdump -eni dpdkTap -Q in and tcpdump -enu dpdkTap -Q out respectively.
Note: you can configure ip address, setup TC on dpdkTap. Also you can run your custom socket programs too. You do not need to invest time on TLDP, ANS, VPP as per your requirement you just need an mechanism to inject and receive packet from Kernel network stack.
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
I'm developing a product that need to integrate with RADIUS server as an authentication method.
When configuring the RADIUS server (IP Address, Port, Shared Secret) I would like to do a "test" in order to check that the configuration is valid - The server is available and it is indeed a RADIUS server, Shared secret is OK.
I did some research on how to do it,
My options are:
Send Access-Request message with fictional user name and password to the RADIUS server
Send Status-Server message to the RADIUS server
RFC 5997 introduces the use of Status-Server Packets in the RADIUS protocol.
This packet extension enabling clients to query the status of a RADIUS server.
The Status-Server is marked as experimental and as Informational RFC rather than as a Standards-Track RFC
My questions are:
Which are the most common \ in use RADIUS server vendors ? MS NPS, FreeRADIUS, Other?
Are these vendors supporting Status-Server request - Do they implementing this packet type ?
If i will use Access-Request, I will receive "Access-Reject" with a failure message in "Reply-Message" attribute. Can i understand the reason for the refusal from that text message? Is there any list of error codes\messages that are part of the Standard ?
Thanks a lot,
Yossi Zrahia
Ad 1) Exact (or even estimate) numbers are hard to come by, but you should expect to encounter FreeRADIUS, Microsoft NPS, Radiator and maybe Cisco ACS/ISE.
Ad 2) FreeRADIUS, Radiator support it. Microsoft NPS and Cisco ACS/ISE do not. If your "test" is used once (upon configuring) I would use option 1 with the Access-Request. If you wish to periodically check the availability and configuration of a RADIUS server, I would suggest implementing both options and allow for configuration of the check as part of the RADIUS configuration:
IP: 1.2.3.4
Port: 1812
Shared Secret: U7tr453cur3
Servercheck: [x] Status-Server
[ ] Access-Request
Ad 3) From RFC2865, section 5.18 (Reply-Message):
"[...] This Attribute indicates text which MAY be displayed to the user. [...] When used in an Access-Reject, it is the failure message. It MAY indicate a dialog message to prompt the user before another Access-Request attempt. [...] The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters."
There apparently are no standard messages specified; however if IP, Port or Shared Secret are configured incorrectly you should not get a response at all, because RFC 2865 specifies:
"A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded."
I want to only capture the traffic sent or destined to my local machine (no promiscuous mode). Nevertheless, broadcast traffic should also be captured.
So, the question is how to open the adapter? Which flags should be used? There is no specific flag for this kind of capture. I only found the following flags:
#define PCAP_OPENFLAG_PROMISCUOUS 1
// Defines if the adapter has to go in promiscuous mode.
#define PCAP_OPENFLAG_DATATX_UDP 2
// Defines if the data trasfer (in case of a remote capture) has to be done with UDP protocol.
#define PCAP_OPENFLAG_NOCAPTURE_RPCAP 4
// Defines if the remote probe will capture its own generated traffic.
#define PCAP_OPENFLAG_NOCAPTURE_LOCAL 8
// Defines if the local adapter will capture its own generated traffic.
#define PCAP_OPENFLAG_MAX_RESPONSIVENESS 16
// This flag configures the adapter for maximum responsiveness.
So, should I open the adapter in promiscuous mode and set an appropriate filter? Or is there a better possibility to achieve this goal (better in terms of less processing by the WinPCAP capture driver)?
Thanks for clarification!
jonas
I want to only capture the traffic sent or destined to my local machine (no promiscuous mode).
Then don't turn promiscuous mode on.
Nevertheless, broadcast traffic should also be captured.
Broadcast traffic will always be captured (unless you specify a filter, such as !broadcast, that explicitly filters it out).
I need to ask few question about Asterisk
1) Does ACL mean by Access Control list here ?If yes than how could i use it?
>ip show user 6001
* Name : 6001
Secret : <Set>
MD5Secret : <Not set>
Context : DLPN_Admin
Language :
AMA flags : Unknown
Transfer mode: open
MaxCallBR : 384 kbps
CallingPres : Presentation Allowed, Not Screened
Call limit : 2147483647
Callgroup : 1
Pickupgroup : 1
Callerid : "test" <6001>
ACL : No
Sess-Timers : Accept
Sess-Refresh : uas
Sess-Expires : 1800 secs
Sess-Min-SE : 90 secs
RTP Engine : asterisk
Codec Order : (ulaw:20,gsm:20)
Auto-Framing: No
2) What is mean by "Require Call Token" in Asterisk Digium GIU on Create new User Panel
3) Is There any command from where i can get users VOICE MAIL password ?
4) What AMI or CLI command set call recording on or off for user ? and if i want that file to be stored on client computer not on server memory what could i do ?
Question 1:
Yes, ACL does stand for Access Control List. You can use the settings "contextpermit/contactdeny" to control what addresses a UA can register from; "permit/deny" to control what addresses a UA can establish calls from (INVITE request); and "directmediapermit/directmediadeny" to control what addresses a UA can use to set up direct media between UAs. Note that all of this is in the sample sip.conf, delivered with Asterisk.
Question 2:
Call Token refers to the IAX setting "requirecalltoken". Older Asterisk clients (1.2 before 1.2.35) don't support call tokens. Note that call tokens were added to address a security vulnerability (AST-2009-006). From the AST notification:
"A lot of time was spent trying to come up with a way to resolve this issue in a way that was completely backwards compatible. However, the final resolution ended up requiring a modification to the IAX2 protocol. This modification is referred to as call token validation. Call token validation is used as a handshake before call numbers are assigned to IAX2 connections.
Call token validation by itself does not resolve the issue. However, it does allow an IAX2 server to validate that the source of the messages has not been spoofed. In addition to call token validation, Asterisk now also has the ability to limit the amount of call numbers assigned to a given remote IP address.
The combination of call token validation and call number allocation limits is used to mitigate this denial of service issue."
Question 3:
No. That doesn't mean you couldn't use AGI to call out to a script with the user's voicemail extension, do the parsing yourself, and put the result in a channel variable.
Question 4:
AMI commands are documented at Asterisk AMI Actions. I'm going to assume that by "set recording" you mean start a Monitor application on some particular channel (and not change CDRs, CELs, etc.) In that case, you'd use the Monitor AMI action to start the recording, and StopMonitor AMI action to stop the recording. Once the file is created, you can move it off the server yourself using AGI or some other externally spawned mechanism.