PJSIP: Why am I able to make calls but logged as unavailable in the Asterisk 16 console? - asterisk

So i can make calls but i'am offline in the console. I don't get notice in the console when I register Why that ? thanks.
PJSIP.conf
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
[7000]
type=endpoint
context=from-internal
disallow=all
allow=g729
transport=transport-udp
auth=7000
aors=7000
[7000]
type=auth
auth_type=userpass
password=7000
username=7000
[7000]
type=aor
qualify_timeout=4.0
qualify_frequency=50
max_contacts=1
Cmd: pjsip show endpoints
Endpoint: 7000 Unavailable 0 of inf
InAuth: 7000/7000
Aor: 7000 1
Transport: transport-udp udp 0 0 0.0.0.0:5060
Cmd: pjsip show endpoint 7000
Endpoint: 7000 Unavailable 0 of inf
InAuth: 7000/7000
Aor: 7000 1
Transport: transport-udp udp 0 0 0.0.0.0:5060

I had to add allow_subscribe=yes ;)
Endpoint: 7000 In use 1 of inf
InAuth: 7000/7000
Aor: 7000 1
Contact: 7000/sip:7000#127.0.0.1:62210;ob a891149c2b Avail 1.464
Transport: transport-udp udp 0 0 0.0.0.0:5060
Channel: PJSIP/7000-00000001/Playback Up 00:00:03
Exten: 999 CLCID: "" <>

You can do outbound call by using sip response "Authentification required" and authentification after that.
For incoming call need "registration", when your device use it asterisk will record ip/port pair for use for incoming calls. That pair can be any if your device have no public ip(NAT).

Related

GOLANG, HTTP having "use of closed network connection" error

I am getting a lot of error like below mentioned,
read tcp xx.xx.xx.xx:80: use of closed network connection
read tcp xx.xx.xx.xx:80: connection reset by peer
//function for HTTP connection
func GetResponseBytesByURL_raw(restUrl, connectionTimeOutStr, readTimeOutStr string) ([]byte, error) {
connectionTimeOut, _ /*err*/ := time.ParseDuration(connectionTimeOutStr)
readTimeOut, _ /*err*/ := time.ParseDuration(readTimeOutStr)
timeout := connectionTimeOut + readTimeOut // time.Duration((strconv.Atoi(connectionTimeOutStr) + strconv.Atoi(readTimeOutStr)))
//timeout = 200 * time.Millisecond
client := http.Client{
Timeout: timeout,
}
resp, err := client.Get(restUrl)
if nil != err {
logger.SetLog("Error GetResponseBytesByURL_raw |err: ", logs.LevelError, err)
return make([]byte, 0), err
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
return body, err
}
Update (July 14):
Server : NumCPU=8, RAM=24GB, GO=go1.4.2.linux-amd64
I am getting such error during some high traffic.
20000-30000 request per minutes, and I have a time frame of 500ms to fetch response from third party api.
netstat status from my server (using : netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n) to get frequency
1 established)
1 Foreign
9 LISTEN
33 FIN_WAIT1
338 ESTABLISHED
5530 SYN_SENT
32202 TIME_WAIT
sysctl -p
**sysctl -p**
fs.file-max = 2097152
vm.swappiness = 10
vm.dirty_ratio = 60
vm.dirty_background_ratio = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.ip_local_port_range = 2000 65535
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_fin_timeout = 5
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
net.core.rmem_default = 31457280
net.core.rmem_max = 12582912
net.core.wmem_default = 31457280
net.core.wmem_max = 12582912
net.core.somaxconn = 65536
net.core.netdev_max_backlog = 65536
net.core.optmem_max = 25165824
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.udp_rmem_min = 16384
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.udp_wmem_min = 16384
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv6.bindv6only = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
error: "net.ipv4.icmp_ignore_bogus_error_messages" is an unknown key
kernel.exec-shield = 1
kernel.randomize_va_space = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
When making connections at a high rate over the internet, it's very likely you're going to encounter some connection problems. You can't mitigate them completely, so you may want to add retry logic around the request. The actual error type at this point probably doesn't matter, but matching the error string for use of closed network connection or connection reset by peer is about the best you can do if you want to be specific. Make sure to limit the retries with a backoff, as some systems will drop or reset connections as a way to limit request rates, and you may get more errors the faster you reconnect.
Depending on the number of remote hosts you're communicating with, you will want to increase Transport.MaxIdleConnsPerHost (the default is only 2). The fewer hosts you talk to, the higher you can set this. This will decrease the number of new connections made, and speed up the requests overall.
If you can, try the go1.5 beta. There have been a couple changes around keep-alive connections that may help reduce the number of errors you see.
I recommend implementing an exponential back off or some other rate limiting mechanism on your side of the wire. There's not really anything you can do about those error, and using exponential back off won't necessarily make you get the data any faster either. But it can ensure that you get all the data and the API you're pulling from will surely appreciate the reduced traffic. Here's a link to one I found on GitHub; https://github.com/cenkalti/backoff
There was another popular option as well though I haven't used either. Implementing one yourself isn't terribly difficult either and I could provide some sample of that on request. One thing I do recommend based off my experience is make sure you're using a retry function that has an abort channel. If you get to really long back off times then you'll want some way for the caller to kill it.

ttyO ports do not have the good port address on QEMU 1.4.0 running image for beagleboard-xm

I'm running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator Ubuntu distribution for 13.04. My image is created using Buildroot beagle_defconfig. I added some pkgs to be able to debug a little.
QEMU call cmd:
`$ sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty`
[sudo] password for emperador:
char device redirected to /dev/pts/3 (label serial1)
char device redirected to /dev/pts/4 (label serial2)
What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side. My problem goes like this:
At the guest kernel boot Im able to see that my UART where enabled
[ 2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
[ 2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
[ 2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
[ 2.966825] console [ttyO2] enabled
[ 2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3
In fact when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD
1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD
2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD
3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD
I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message:
[root#enu driver]# setserial -a /dev/ttyO0
/dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72
Baud_base: 3000000, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
The same goes with ttyO2.
I tried to set some settings to any of the ttyO with setserial but I always get the same message:
[root#enu ~]# setserial /dev/ttyO0 uart 8250
setserial: can't set serial info: Invalid argument
[root#enu ~]# setserial /dev/ttyO0 port 0x4806a000
setserial: can't set serial info: Invalid argument
While looking at guest /proc/tty/drives this is what we see
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
sdio_uart /dev/ttySDIO 249 0-7 serial
acm /dev/ttyACM 166 0-31 serial
ttyprintk /dev/ttyprintk 5 3 console
OMAP-SERIAL /dev/ttyO 253 0-3 serial
serial /dev/ttyS 4 64-95 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty 4 1-63 console
Basically I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured.
/sys/class/tty show that tty drivers had been linked to a serial device.
has I showed up before, only omap uarts have been initialized and attached to ttyO*. notice that the console is been redirected ttyO2 by kernel configs. but because I added -serial stdio, console is been redirected to the terminal that invoked QEMU.
If I redirect the console using at first -serial pty instead of -serial stdio , I'm able to prompt the console in minicom by opening the pty created on the host side. Still nothing happen on the others pty created on the host side to communicate across other ports.
On host side I open /dev/pts/3 and /dev/pts/4 with minicom or by doing cat on them
On guest side:
Whent I do echo "test" > /dev/ttyO0 or 1 or 3 nothing. but when I do it on ttyO2, "test" prompt on the console terminal (which is normal).
now when using any of the ttyS:
echo "test" > /dev/ttyS0
I get
-bash: echo: write error: Input/output error
I made some research about this error and what I found is that is could be many things. But one thing that I noticed was that no device beside serial has been assigned to ttyS. and looking at /proc/tty/driver/serial we see this :
serinfo:1.0 driver revision:
0: uart:unknown port:00000000 irq:0
1: uart:unknown port:00000000 irq:0
2: uart:unknown port:00000000 irq:0
3: uart:unknown port:00000000 irq:0
also setserial -a /dev/ttyS0 confrim this:
/dev/ttyS0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
I managed to do serial communication with muliples ports usig grml image on a x86 architecture. So its seems my host side is fine.
If anyone have ever made something like this work before on QEMU -M beaglexm or any other ARM architecture, I would gladly take any details on the VM used, QEMU's version and distribution as well as the kernel details and image configs used.
I found what my problem was, QEMU ins't mapping the serial chardev of any extra -serial pty.
After doing the this Invoke command:
sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clonix -serial stdio -device usb-mouse -device usb-kbd -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/5 (label compat_monitor0)
char device redirected to /dev/pts/7 (label serial1)
char device redirected to /dev/pts/10 (label serial2)
We can see that 2 extra serials where created with the label serial 1 and 2.
But if I look at the tree info
(qemu) info qtree
dev: omap_uart, id "uart4"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart4
irq 3
mmio 0000000049042000/0000000000001000
dev: omap_uart, id "uart3"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = serial0
irq 3
mmio 0000000049020000/0000000000001000
dev: omap_uart, id "uart2"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart2
irq 3
mmio 000000004806c000/0000000000001000
dev: omap_uart, id "uart1"
revision = 82
mmio_size = 4096
baudrate = 812500
chardev = uart1
irq 3
mmio 000000004806a000/0000000000001000
We clearly see that just the label serial0 was attached to a uart (the one setted to be the console). The other labels (serial1 and serial2) are no where to be found.
With the working image of grml that jofel was realy nice to tell me we see this:
dev: i440FX-pcihost, id ""
irq 0
bus: pci.0
type PCI
dev: PIIX3, id ""
addr = 01.0
romfile = <null>
rombar = 1
multifunction = on
command_serr_enable = on
class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100)
bus: isa.0
type ISA
dev: isa-serial, id ""
index = 2
iobase = 0x3e8
irq = 4
chardev = serial2
wakeup = 0
isa irq 4
dev: isa-serial, id ""
index = 1
iobase = 0x2f8
irq = 3
chardev = serial1
wakeup = 0
isa irq 3
dev: isa-serial, id ""
index = 0
iobase = 0x3f8
irq = 4
chardev = serial0
wakeup = 0
isa irq 4
all 3 serial lebels were attached to a chardev.
Now I just have to ask a new question about how making QEMU to link those lables to my beagleboard uarts.
Also I would like to add I think that setserial did not outputed any info about ttyO's because it doesn't support omap uarts. setserial ? shows what devices are supported. In the case of the ttyS's, I think its because the tty drivers are installed but there is no other type of uarts bisede omap uarts emulated for bealgeboard in QEMU.
Thanks alot for everyone that took a look on this question and specialy jofel.

meaning of kannel status

we have configured kannel, and the status look like
SMS: received 0 (0 queued), sent 15133 (0 queued), store size 0
SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (3.08,15.23,0.02) msg/sec
DLR: received 14232, sent 0
DLR: inbound (11.45,5.64,0.02) msg/sec, outbound (0.00,0.00,0.00) msg/sec
DLR: 980 queued, using internal storage
Box connections:
smsbox:vsmsc, IP 127.0.0.1 (0 queued), (on-line 8d 21h 38m 41s)
smsc1[smsc1] SMPP:xxxxx.xxxxx.com:2775/2775:xxxxx:SMPP (online 769120s, rcvd: sms 0 (0.00,0.00,0.00) / dlr 1 (0.00,0.00,0.00), sent: sms 1 (0.00,0.00,0.00) / dlr 0 (0.00,0.00,0.00), failed 0, queued 0 msgs)
in the DLR inbound, it showing (11.45,5.64,0.02) msg/sec. There is 3 value inside (). What is the meaning of each?
thanks
Average for the last minute;
Average for the last 5 minutes;
Average for all of runtime.

Production Thin Best Practices

I'm using Thin as a server for Faye. To do that, I use something like this:
require 'faye'
bayeux = Faye::RackAdapter.new(:mount => '/faye', :timeout => 25)
bayeux.listen(9292)
The Thin process is monitored by God and all is well in Development.
However, I'm not sure if this is the right setup for a production configuration. What I would like to know is how is this setup (with no Nginx or HAProxy at the front) is going to perform in a production environment.
this is my god config.
#Faye
ports = [9292, 9293, 9294, 9295]
ports.each_with_index do |port, id|
God.watch do |w|
w.dir = "#{rails_root}"
w.name = "faye-#{port}"
w.group = "faye"
w.interval = 30.seconds
w.start = "thin start -R #{rails_root}/faye.ru -e production -p #{port} -P #{rails_root}tmp/pids/faye-#{port}.pid"
w.stop = "thin stop -P #{rails_root}tmp/pids/faye-#{port}.pid"
w.log = "#{rails_root}/log/god_node.log"
#w.uid = 'server'
#w.gid = 'server'
# restart if memory usage is > 500mb
w.transition(:up, :restart) do |on|
on.condition(:memory_usage) do |c|
c.above = 500.megabytes
c.times = 2
end
end
# determine the state on startup
w.transition(:init, { true => :up, false => :start }) do |on|
on.condition(:process_running) do |c|
c.running = true
end
end
# determine when process has finished starting
w.transition([:start, :restart], :up) do |on|
on.condition(:process_running) do |c|
c.running = true
c.interval = 10.seconds
end
# failsafe
on.condition(:tries) do |c|
c.times = 5
c.transition = :start
c.interval = 10.seconds
end
end
# start if process is not running
w.transition(:up, :start) do |on|
on.condition(:process_running) do |c|
c.running = false
end
end
end
end
and i'm using nginx to load balancing.
I have been using thin to run faye with redis. making sure to set
Faye::WebSocket.load_adapter('thin')
all traffic goes through haproxy (the first one is named proxied as I redirect all traffic to https)
frontend proxied
bind 127.0.0.1:81 accept-proxy
timeout client 86400000
default_backend nginx_backend
acl is_websocket hdr(Upgrade) -i WebSocket
acl is_websocket hdr_beg(Host) -i ws
use_backend socket_backend if is_websocket
backend nginx_backend
balance roundrobin
option forwardfor #except 127.0.0.1 # This sets X-Forwarded-For
timeout server 30000
timeout connect 4000
server nginx1 localhost:8081 weight 1 maxconn 20000 check
backend socket_backend
balance roundrobin
option forwardfor except 127.0.0.1 # This sets X-Forwarded-For
timeout queue 5000
timeout server 86400000
timeout connect 86400000
server socket1 localhost:3100 weight 1 maxconn 20000 check
server socket2 localhost:3101 weight 1 maxconn 20000 check
server socket3 localhost:3102 weight 1 maxconn 20000 check
server socket4 localhost:3103 weight 1 maxconn 20000 check
...
if it is http traffic I route it through nginx which forwards to the same set of thin instances if it includes the /faye path.
I am not an haproxy expert but this is working for websocket and long poll connections.

Correlation between ICMP error messages and IP packets that generated them

I need to send a bunch of IP packets that I'm sure will trigger an ICMP TTL-expired error message. How exactly can I associate each error message with the packet that generated it? What field in the ICMP header is used for this?
Should I rather use some custom ID number in the original IP header, so that I can tell which error message corresponds to which packet? If so, which field is most suitable for this?
The body of ICMP TTL Expired messages must include the IP header of the original packet (which includes the source-port / destination-port) and 64 bits beyond the original header.
Based on timing and that header information, you can derive which packet triggered the TTL-expired message.
I am including a sample triggered by an NTP packet below...
See RFC 792 (Page 5) for more details.
ICMP TTL-Expired Message
Ethernet II, Src: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00), Dst: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Destination: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
Address: 78:2b:cb:37:4c:7a (78:2b:cb:37:4c:7a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
Address: JuniperN_c3:a0:00 (b0:c6:9a:c3:a0:00)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 172.25.116.254 (172.25.116.254), Dst: 172.25.116.10 (172.25.116.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x86d7 (34519)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xb3b1 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.254 (172.25.116.254)
Destination: 172.25.116.10 (172.25.116.10)
Internet Control Message Protocol
Type: 11 (Time-to-live exceeded)
Code: 0 (Time to live exceeded in transit)
Checksum: 0x4613 [correct]
Internet Protocol, Src: 172.25.116.10 (172.25.116.10), Dst: 172.25.0.11 (172.25.0.11)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 36
Identification: 0x0001 (1)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 0
[Expert Info (Note/Sequence): "Time To Live" only 0]
[Message: "Time To Live" only 0]
[Severity level: Note]
[Group: Sequence]
Protocol: UDP (0x11)
Header checksum: 0xee80 [correct]
[Good: True]
[Bad : False]
Source: 172.25.116.10 (172.25.116.10)
Destination: 172.25.0.11 (172.25.0.11)
User Datagram Protocol, Src Port: telindus (1728), Dst Port: ntp (123)
Source port: telindus (1728)
Destination port: ntp (123)
Length: 16
Checksum: 0xa7a1 [unchecked, not all data available]
[Good Checksum: False]
[Bad Checksum: False]

Resources