Tag: VoIP
Some info on MagicJack
by starprowler on Dec.27, 2010, under VoIP
Came across this interesting article on MagicJack at Digital Offensive. Got to try it out soon.
Linksys SPA-3102
by starprowler on Sep.05, 2010, under VoIP
The SPA3102 that Kay uses was stuck in the off-hook state after an incoming call. This device is installed in a remote location he had to reboot it over the network.
Since it does not have “Reboot” button unlike most appliances, I asked Kay to browse to http://<spa.ip.address>/admin/reboot. That did the trick, he was thankful to yours truly, since it saved him a 3 hour trip!
Troy and the Draytek 2820Vn
by starprowler on Aug.15, 2009, under Networking, VoIP
The Draytek 2820Vn is a great device for home and small-offices. It has two WAN ports; ADSL and Ethernet. Excellent VPN capabilities 32 simultaneous VPN tunnels (IPSec, PPTP, L2TP and L2TP over IPSec.)
In order to get point to point voice working either on VPN or LAN you need to ensure that
- the “External IP :” under VoIP -> SIP Accounts is the private IP of the router itself
- the SIP account in use is configured with “Register via LAN/VPN”
- “NAT Traversal Support” is set to “None”
Troy was trying in vain to get voice calls working. We hit on this combination after quite a bit of messing the parameters. The predecessor of the Draytek 2820Vn (the Draytek 2800VG) does not need these fiddly parameters configured and works just fine without these settings. This coupled with the fact that he’s bought 5 of these devices to internetwork the branch offices of a relative’s company, caused this networking boffin a lot of frustration.
Troy has since gone back to meddling with his favourites Cisco and HP ProCurve, thankful to your truly for having helped put this ordeal behind him!
Asterisk and AVAYA
by starprowler on Aug.15, 2009, under VoIP
Some info I posted on ChipOverclock’s blog:
Thot i’d post my experiences with the AVAYA SIP phones.
- The current version of the firmware for the 46xx phones still doesn’t seem to support the message waiting indicator (MWI) light. And as a side-effect of pending voice mail, these phones seem to think they are not registered after a seeming random period of time, refusing to allow outgoing calls. I had to disable voice mail on all extensions with AVAYA phones. Wasn’t too bad, I could live without the MWI.
- The 1.xx version of SIP firmware for the 9620/9630/9640 series of phones would register fine on Asterisk, allow outgoing calls but refuse to accept incoming calls.
- AVAYA have recently release version 2 of the SIP firmware for the 96xx phones. Thought I’d give it a try the other day. I was pleasantly surprised to find that it worked perfectly, including the MWI!! Excellent speaker-phone, and great voice quality.
I’ve been testing it for about 4 days now and am totally happy with the results.
Original post
my experiments with Cisco 7940 IP phone
by starprowler on Jun.27, 2009, under VoIP
12:40 AM 09 Dec 2007
Seem to have figured out the strange and seemingly erratic behaviour of the Cisco 7940.
Quick answer… in the SIP<mac_address>.cnf file enable NAT:
# NAT/Firewall Traversal
nat_enable: “1” ; <—- default is “0”. Have no idea why this works but…
nat_address: “”
voip_control_port: “5061”
start_media_port: “19000”
end_media_port: “20000”
nat_received_processing: “0”
I chanced on this when poring over the SIP logs. I noticed that the requests from the phone was coming from random ports. The SIP read said…
<— SIP read from 192.168.2.130:50218 —>
… but the Contact: SIp field said…
Contact: <sip:[email protected]:5060;transport=udp>
However, * responded…
<— Transmitting (NAT) to 192.168.2.130:50218 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bK4fba995f;received=192.168.2.130
Further down… i saw….
[Dec 8 17:32:01] VERBOSE[2565] logger.c: Sending to 192.168.2.130 : 50218 (NAT) ; <—!!
[Dec 8 17:32:01] VERBOSE[2565] logger.c: Using INVITE request as basis request – [email protected]
[Dec 8 17:32:01] VERBOSE[2565] logger.c: Found no matching peer or user for ‘192.168.2.130:50218’
wierd?? Dunno. So * was sending its reponses to the 50218 port in the above case, and obviously the phone wasn’t listening at that port! This meant that the 200 OK responses were not being received by the phone. So finally hit on this setting… didn’t make sense, but tried it coz that would be one setting that would affect source and target ports. It worked! I hope this is the last of my travails with the Cisco 7940 phone. All works fine… including the MWI! 🙂
After this the sip show peers, showed me….
6112/6112 192.168.2.130 D N 5061 Unmonitored
^^^^-!!! This came from the NAT/Firewall traversal setting.
Obviously the Phone firmware was using a random port (i.e., ignoring this setting) when used with a nat_enable: 0 setting.