Using Wireshark to capture the packets of Remote Machine

Remote capture using wireshark:

First of, Create the pipe

my@desktop:~$ mkfifo /tmp/pipes/cap_fw

“/tmp/pipes/” is where I create my pipes, feel free to use whatever directory you prefer.

“cap_fw” is the name of the pipe I selected.

Start tcpdump remotely with ssh from the desktop where you have wireshark installed:

my@desktop:~$ ssh root@<firewall> "tcpdump -s 0 -U -n -w - -i eth1 not port 22" > /tmp/pipes/cap_fw

Replace <firewall> with the name or ip address of your remote server.

The options I used are:

-s 0 : use the required length to catch whole packets

-U : packet-buffering – write packet to pipe as soon as it is captured (as opposed to waiting for the buffer to fill)

-n : no address-to-name conversion (you can let wireshark do this if you want)

-w - : write output to standard output

-i eth1 : capture from interface eth1 – change to match your setup

not port 22 : leave out any packets from / to port 22. This is needed as we use ssh to connect to out firewall, so that we don’t capture the captured packets again… If you need to examine port 22 on your server, use ssh over an alternative port.

> /tmp/pipes/cap_fw : redirect the output to our pipe.

While tcpdump is capturing packets and sending them to the pipe, open another terminal, start wireshark and use the pipe as the input

my@desktop:~$ wireshark -k -i /tmp/pipes/cap_fw

Here the options mean:

-k : start immediately

-i /tmp/pipes/cap_fw : use our pipe as the “interface”

And you’re up and running!

Bash Conditional Expressions

Bash Conditional Expressions

Conditional expressions are used by the [[ compound command and the test and [ built-in commands.
Expressions may be unary or binary. Unary expressions are often used to examine the status of a file. There are string operators and numeric comparison operators as well. If the file argument to one of the primaries is of the form /dev/fd/N, then file descriptor N is checked. If the file argument to one of the primaries is one of /dev/stdin, /dev/stdout, or /dev/stderr, file descriptor 0, 1, or 2, respectively, is checked.
When used with [[, the ‘<’ and ‘>’ operators sort lexicographically using the current locale. The test command uses ASCII ordering.
Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself.

-a file

True if file exists.

-b file

True if file exists and is a block special file.

-c file

True if file exists and is a character special file.

-d file

True if file exists and is a directory.

-e file

True if file exists.

-f file

True if file exists and is a regular file.

-g file

True if file exists and its set-group-id bit is set.

-h file

True if file exists and is a symbolic link.

-k file

True if file exists and its "sticky" bit is set.

-p file

True if file exists and is a named pipe (FIFO).

-r file

True if file exists and is readable.

-s file

True if file exists and has a size greater than zero.

-t fd

True if file descriptor fd is open and refers to a terminal.

-u file

True if file exists and its set-user-id bit is set.

-w file

True if file exists and is writable.

-x file

True if file exists and is executable.

-G file

True if file exists and is owned by the effective group id.

-L file

True if file exists and is a symbolic link.

-N file

True if file exists and has been modified since it was last read.

-O file

True if file exists and is owned by the effective user id.

-S file

True if file exists and is a socket.

file1 -ef file2

True if file1 and file2 refer to the same device and inode numbers.

file1 -nt file2

True if file1 is newer (according to modification date) than file2, or if file1 exists and file2 does not.

file1 -ot file2

True if file1 is older than file2, or if file2 exists and file1 does not.

-o optname

True if the shell option optname is enabled. The list of options appears in the description of the -o option to the set builtin (see The Set Builtin).

-v varname

True if the shell variable varname is set (has been assigned a value).

-R varname

True if the shell variable varname is set and is a name reference.

-z string

True if the length of string is zero.

-n string

string

True if the length of string is non-zero.

string1 == string2

string1 = string2

True if the strings are equal. When used with the [[ command, this performs pattern matching as described above (see Conditional Constructs).
‘=’ should be used with the test command for POSIX conformance.

string1 != string2

True if the strings are not equal.

string1 < string2

True if string1 sorts before string2 lexicographically.

string1 > string2

True if string1 sorts after string2 lexicographically.

arg1 OP arg2

OP is one of ‘-eq’, ‘-ne’, ‘-lt’, ‘-le’, ‘-gt’, or ‘-ge’. These arithmetic binary operators return true if arg1 is equal to, not equal to, less than, less than or equal to, greater than, or greater than or equal to arg2, respectively. Arg1 and arg2 may be positive or negative integers.

vim Remove Comments using REGEX | Remove comments of Asterisk Configuration files

You can try this command:

:g/^\(#\|$\)/d

Or (Use ; for the Asterisk PBX configuration files.)

:g/\v^(#|;)/d

• \| is for alternation
• \v is very magic (minimal backslash escape)

WebRTC Video Resolutions

Resolution is the number of pixels in an image.

In general terms, the higher the resolution, the better the image quality.

The following terms are used for different video resolution values that are common in video calling for WebRTC:

• QVGA – 320×240
• VGA – 640×480
• 720p (or HD 720) – 1280×720
• 1080p (or HD 1080) – 1920×1080
• 4K – 4096×2160

WebRTC isn’t limited in the resolution it can support. The limit is caused by browser implementations, processor capabilities and network conditions, as the higher the resolution, the more computation and bandwidth it requires.

Most WebRTC implementations to date have been able to reach 720p resolutions, with 1080p starting to be introduced.

SIPP installation and testing Asterisk with SIPP stress test tool

1. Install required packages
$ sudo apt-get install build-essential libncurses5-dev

2. Download, extract and compile SIPp
$ wget "http://downloads.sourceforge.net/project/sipp/sipp/3.2/sipp.svn.tar.gz?r=&ts=1314783436&use_mirror=puzzle" -O sipp.svn.tar.gz
$ tar -xzf sipp.svn.tar.gz
$ cd sipp.svn
$ make

3. Set up the SIP server
Note these instructions are for configuring the Asterisk open source PBX, for other platforms you will need to consult the documentation.

First, define the SIP peer by adding to the end of sip.conf:
[sipp]
type=friend
context=sipp
host=dynamic
port=6000
user=sipp
canreinvite=no
disallow=all
allow=alaw
allow=ulaw

Next set up some extensions that we will use to test by adding to the end of extensions.conf (this assumes a default Asterisk installation where the demo context exists, if not then point calls at some other context that has e.g. an IVR menu or similar):
[sipp]
exten => 1001,1,Answer
exten => 1001,n,SetMusicOnHold(default)
exten => 1001,n,WaitMusicOnHold(20)
exten => 1001,n,Hangup
exten => 1002,1,Answer
exten => 1002,n,Goto(demo,s,1)
exten => 1002,n,Hangup

Finally load the new configuration into asterisk:
$ asterisk -rx 'module reload'

4. Start testing

There are various simple tests that can be done without creating your own scenarios, such as:

1. Simple concurrent call test

$ ./sipp -sn uac -d 10000 -s 1001 <asterisk's IP address> -l 10
This will execute 10 concurrent calls (the -l parameter) with each call lasting 10s (the -d parameter in ms) to extension 1001. Note that this simple test does not actually establish an RTP connection, and thus does not actually place full load on the system.

2. Testing with media

$ ./sipp -sn uac -d 10000 -s 1002 <asterisk's IP address> -l 10 -mp 5606
This executes 10 concurrent calls, each lasting 10s to extension 1002 using the ulaw codec.

When running SIPp will display a screen showing various statistics such as the number of calls in progress, the number completed and some information about the SIP messages it has sent. It also shows any errors it has received. To stop a test, simply press ‘q’.

By playing around with the duration (-d) and limit (-l) parameters you can normally find the limit of your system’s scalability. It is also often an idea to leave the test running at a reasonable call level for a long period of time, this will help identify any memory leaks or similar that will likely cause problems over time.

Note that while SIPp will verify that an RTP connection is established, it will not check the quality – the simplest way to do this is to set up your call load using SIPp, then make a manual call through the system to check the quality is acceptable.

Notes

• If the machine you are running SIPp on has multiple network interfaces, it may not correctly identify which interface to use for the outbound traffic – to correct this use the -bind_local option, e.g. to use the IP address 192.168.1.1 for outbound traffic you would add “-bind_local 192.168.1.1“
• If you stop a test without letting all the calls clean up, and then attempt to start another, the new one may report errors as it receives SIP messages from the server relating to calls initiated by the previous test – it’s always best to let a test fully clean up

Installing FFmpeg in Ubuntu 14.04 from source

Installing FFmpeg  in Debian Ubuntu 14.04 :

Build and install FFmpeg:

cd /usr/local/src
wget -c http://ffmpeg.org/releases/ffmpeg-1.0.2.tar.gz
tar zxvf ffmpeg-1.0.2.tar.gz
cd ffmpeg
./configure --extra-cflags="-fPIC" --extra-ldflags="-lpthread" --enable-pic \
--enable-memalign-hack --enable-shared --disable-static --disable-network \
--disable-protocols --disable-pthreads --disable-devices --disable-filters \
--disable-bsfs --disable-muxers --disable-demuxers --disable-parsers \
--disable-hwaccels --disable-ffmpeg --disable-ffplay --disable-ffserver \
--disable-encoders --disable-decoders --disable-zlib --enable-gpl --disable-debug \
--enable-encoder=h263 --enable-encoder=h263p --enable-decoder=h263 \
--enable-encoder=mpeg4 --enable-decoder=mpeg4 --enable-libx264 \
--enable-encoder=libx264 --enable-decoder=h264
make -j `getconf _NPROCESSORS_ONLN`
make install
ldconfig

Asterisk behind the NAT setting

Asterisk behind NAT

The Asterisk Server is behind NAT The Asterisk server could be on the LAN (or in a DMZ) with a NAT firewall between it and the Internet. When it communicates with external peers or devices, the network connections have to pass through the local NAT device. The remote device that is connecting to Asterisk is behind NAT Suppose that your Asterisk server is connected directly to the Internet. Provided your system is made reasonably secure (e.g. through firewall rules) there can be significant benefits in having it directly connected to the Internet. However, you are unlikely to be able to control the networking environment of the devices that connect to it. If remote users have IP phones that register with your Asterisk server, it is very likely that those phones will be behind a NAT device at the far end. Asterisk is behind one NAT and the remote device is behind another This is an unattractive situation for Asterisk to handle and should generally be avoided if possible. However, it can be made to work provided suitable NAT traversal solutions are applied at both ends.

When the Asterisk server is behind a local NAT router

Settings within the sip.conf file when you have a static IP address The externip parameter in sip.conf tells Asterisk what the external IP address is for the NAT/firewall/router. This is the address that external devices on the Internet must use to reach the Asterisk server. If you are unsure what this address is, ask your system administrator or open a web browser on the Asterisk server and point it at http://whatismyip.com or http://www.amibehindnat.com The externhost parameter in sip.conf may be used to tell Asterisk the external address of your NAT/firewall/router in the form of a FQDN. It is an alternative to externip. You must either use externip or externhost, not both. This parameter is the key to solving the NAT problem if your ISP has not allocated you with a static IP address. The externrefresh parameter in sip.conf works in conjunction with externhost. It tells asterisk how often to query the host name using DNS. I recommend you set it to a higher value than the default - perhaps 600. The localnet parameter in sip.conf is used to tell Asterisk which addresses are local. This is important because Asterisk will substitute the value given in externip for its own local address whenever it thinks it is communicating with a remote peer or device. The only way it knows that a device is local, is through the IP address of that device being within the range specified by localnet. For example: [general] externip=63.182.70.1 localnet=192.168.0.0/255.255.255.0 localnet=192.168.2.0/255.255.255.0 Note how you can specify several different subnets using the localnet parameter - simply put each one on a new line. Settings within the sip.conf file when you have a dynamic IP address Internet Service Providers normally charge extra to provide one or more static IP addresses - the option may not even be available if you have a domestic rather than a business broadband package. If your public IP address is dynamic (allocated by your provider's DHCP service) then you will still be able to use Asterisk behind your firewall provided it supports automatic registration with a Dynamic DNS service such as DynDNS.com. The basic service is free so it is worth a try. First, you must register with DynDNS.com (or one of the alternative dynamic DNS service providers), then instruct your firewall to use the service and finally you must use the externhost parameter to specify your host name. Don't use externip, but do specify externrefresh and localnet as described above. I'm using Trixbox/FreePBX. Where do I set these parameters? Just edit the file /etc/asterisk/sip_general_custom.conf and put the parameters in there, then restart the asterisk service or reboot the machine. Settings on the local NAT/firewall/router If you are unable to make configuration changes (or have changes made on your behalf) on the local NAT/firewall/router device, then you are unlikely to be able to make Asterisk work for SIP connections to remote peers and devices. The suggestions given here assume that you do have access to the configuration rules on this device. If not, consider using the IAX protocol instead. The NAT/firewall/router should be configured to allow inbound UDP connections to your Asterisk server on the primary SIP port (usually 5060). It must also be configured to allow inbound UDP connections to the same ports on the Asterisk server as are defined in the rtp.conf file. The default port range in rtp.conf is 10000 to 20000. However, it is recommended that the range of port numbers assigned for RTP is reduced by editing rtp.conf, changing the parameter settings and then restarting Asterisk. It will usually be sufficient to have a range that is approximately twice the maximum number of simultaneous calls, plus a few on top for good measure. When configuring your NAT/firewall/router device, you will probably need to find the settings for "port forwarding" or "one-to-one" NAT. Make sure your NAT device does not use port address translation. i.e. if your Asterisk server expects to receive SIP messages on port 5060, make sure you also use port 5060 on the WAN port of your NAT device to forward these messages. Similarly, make sure the same range of port numbers are forwarded on the WAN port for RTP as will receive the RTP on the Asterisk server.

When the remote devices are behind a NAT router

Settings within the sip.conf file The nat parameter in sip.conf tells Asterisk that the remote device is behind a NAT router. There are a number of options for this parameter, but the most likely to work with NAT'd remote devices is nat=yes. You should set this parameter for each peer or device in sip.conf - i.e. don't simply use a default setting for all peers and devices unless you fully understand the implications of doing so. The qualify parameter in sip.conf tells Asterisk to send a kind of ping message to the remote device about every 30 seconds. This can be very helpful when connected to a remote device behind NAT because it forces the NAT router to keep the connection open. Normally, NAT routers will automatically close existing connections if there is no activity on them for more than a preset time. The time that must elapse before a connection is dropped will vary from one manufacturer to another, but it will almost always be more than 30 seconds. It also has a another benefit because it allows Asterisk to know if the connection is still working. For example: [peer1] type=peer nat=yes qualify=yes Checking your remote devices From the Asterisk CLI (Command Line Interface) type the command "sip show peers". This will report back a list of all peers/devices configured in sip.conf and will show if they have registered successfully. It will also show if they are still reachable provided you specified qualify=yes. Settings on the remote NAT/firewall/router Very similar rules apply to the configuration of the remote NAT/firewall/router as those described above for the local firewall. However, the settings on the remote firewall need to be matched to the ports used by the remote device. If the remote device is an IP phone you will ideally want to check the phone's configuration and find out what port numbers it uses for SIP messaging (usually UDP port 5060) and for RTP. Then set port forwarding on the remote firewall for those ports. Fortunately, the solutions available for remote devices, especially IP phones, are more wide ranging than those available for the Asterisk server. Firstly, most modern IP phones will be able to use a STUN server. This is an incredibly useful option and you should certainly try to switch on STUN on all the remote devices if available. STUN can take advantage of symmetrical RTP sessions on the server (i.e. sessions where the server can receive RTP audio on the same port as it uses to send the RTP audio). This option is enabled on your Asterisk server by setting "nat=yes" as described above. Also, many IP phones will recognise and use other NAT traversal techniques including sending "keep-alive" packets after registration (similar to "qualify=yes"). source : smartvox