Experimental VoIP Setup 1.2 2009-11-26
Changelog 1.1 -> 1.2:
Router: Running: Added Inadyn
Router: DDNS: Inserted
Router: Milkfish: Changed
Phone: Account 1: Provider 2 data went to here
Phone: Account 2: Provider 1 data went to here
Phone: Account 1: Register Expiration: 60 minutes -> 15 minutes
Phone: Account 2: Register Expiration: 60 minutes -> 15 minutes
Phone: Account 4: Register Expiration: 60 minutes -> 15 minutes
Timetable: Phone is switched off: 0202 -> 0257
Timetable: Phone is switched on: 0432 -> 0332
Observation 1: Text changed
Observation 4: Text enlarged
Observation 7: Text changed
Observation 9: Text truncated
TODO 2: Removed
TODO 3: Removed
TODO 4: Renamed TODO 4 -> TODO 2
TODO 5: Removed
Equipment:
ADSL Modem: D-Link DSL-320B, Annex A/L/M, Hardware version D1, Firmware version EU_1.00
Router: Linksys WRT54GL v1.1, Firmware version DD-WRT v24-presp2 (07/21/09) voip - build 12533
Phone: Grandstream GXP2010, Hardware version HW0.2B, Firmware version 1.2.2.19, Bootloader version 1.1.6.6
Time Switch: Conrad DCF Time Switch Everflourish EMT707RCC
Configuration + Some Info:
ADSL: Mode: Bridge mode with 1483 bridged IP LLC as the connection type
ADSL: ATM Parameter: Virtual Path Identifier (VPI): 8
ADSL: ATM Parameter: Virtual Channel Identifier (VCI): 32
ADSL: ADSL Modem IP address: Fixed address 192.168.1.1 (a modem firmware bug does not allow to change that)
ADSL: ADSL Modem Subnet Mask: 255.255.255.0
ADSL: Advanced ADSL Settings: Modulation Type: Autosense
ADSL: Advanced ADSL Settings: Capability Bitswap Enable: Yes
ADSL: Advanced ADSL Settings: Capability SRA Enable: No
ADSL: Status Info: Downstream rate: 3004 Kbps
ADSL: Status Info: Upstream rate: 317 Kbps
Router: WAN connection type: PPPoE
Router: WAN IP address type: Variable Public Class A Address
Router: WAN MTU: Manual 1492
Router: LAN IP address: Fixed address 10.xxx.yyy.15
Router: Running: Inadyn, DHCP, NTP, WLAN, DNSMasq, Syslogd, Milkfish, SPI Firewall, QoS, HTTP, Cron
Router: DDNS: DDNS Service: DynDNS.org
Router: DDNS: User Name: <dyndnsUserName>
Router: DDNS: Password: <dyndnsPassWord>
Router: DDNS: Host Name: <dyndnsHostName>.dyndns.org
Router: DDNS: Type: Dynamic
Router: DDNS: Wildcard: <empty>
Router: DDNS: Force Update Interval: 10 days
Router: Setup: Advanced Routing: Operating Mode: Gateway
Router: Wireless: Basic Settings: Wireless Mode: AP
Router: Wireless: Basic Settings: Wireless Network Mode: G-Only
Router: Wireless: Basic Settings: Network Configuration: Bridged
Router: Wireless: Wireless Security: Security Mode: WPA2 Personal
Router: Wireless: Wireless Security: WPA Algorithms: AES
Router: Services: Services: DNSMasq: Enabled
Router: Services: Services: Local DNS: Disabled
Router: Milkfish: Main Switch: Enabled
Router: Milkfish: From-Substitution: Yes
Router: Milkfish: From-Domain: <dyndnsHostName>.dyndns.org
Router: Milkfish: Milkfish Username: <empty>
Router: Milkfish: Milkfish Password: <empty>
Router: Milkfish: SIP Trace: Disabled
Router: Milkfish: Dynamic SIP: Disabled
Router: Milkfish: SIP Database: Local Subscribers: User 1: sip:<nonnumericBluesipIdent>@bluesip.net
Router: Milkfish: SIP Database: Local Subscribers: User 2: sip:<numericTerrasipIdent>@terrasip.net
Router: Milkfish: SIP Database: Local Subscribers: User 3: <internalPhoneNumber>
Router: Milkfish: SIP Database: Local Subscribers: Password 1: <bluesipPassWord>
Router: Milkfish: SIP Database: Local Subscribers: Password 2: <terrasipPassWord>
Router: Milkfish: SIP Database: Local Subscribers: Password 3: <internalPassWord>
Router: Milkfish: Advanced DynSIP Settings: DynSIP Domain: <empty>
Router: Milkfish: Advanced DynSIP Settings: DynSIP Update URL: <empty>
Router: Milkfish: Advanced DynSIP Settings: DynSIP Username: <empty>
Router: Milkfish: Advanced DynSIP Settings: DynSIP Password: <empty>
Router: Security: Firewall: SPI Firewall: Enabled
Router: NAT/QoS: Static Port Forwarding: None
Router: NAT/QoS: UPnP: Off
Router: NAT/QoS: QoS: Start QoS: Enabled
Router: NAT/QoS: QoS: Port: WAN
Router: NAT/QoS: QoS: Packet Scheduler: HTB
Router: NAT/QoS: QoS: Uplink: 150 kbps (well-adjusted, critical influence on the audio quality)
Router: NAT/QoS: QoS: Downlink: 2500 kbps (in fact, this value does not reduce the download rate of 3000 kbps)
Router: NAT/QoS: QoS: Optimize for Gaming: No
Router: NAT/QoS: QoS: Service Priority ntp: Premium (currently important)
Router: NAT/QoS: QoS: Service Priority rtp: Premium (talks are possible, even under load)
Router: NAT/QoS: QoS: Service Priority sip: Premium (phone remains registered, even under load)
Router: NAT/QoS: QoS: MAC Priority Grandstream GXP2010 Phone: Premium
Router: NAT/QoS: QoS: Ethernet Port Priority Port1 ... Port4: Exempt, 100M
Router: Admin: Management: Router Management: Overclocking: 216 MHz
Router: Admin: Keep Alive: Schedule Reboot: At a set Time: <routerRebootTime> Everyday
Router: Admin: Commands: Firewall: Line 1: ifconfig vlan1:0 192.168.1.15 netmask 255.255.255.0 (modem access)
Router: Admin: Commands: Firewall: Line 2: iptables -t nat -I POSTROUTING -o vlan1 -d 192.168.1.15/24 -j MASQUERADE (modem access)
Phone: Settings: IP address: Fixed address 10.xxx.yyy.71 (but via DHCP)
Phone: Settings: Time Zone: GMT+1:00
Phone: Settings: Daylight Savings Time Rule: 3,-1,7,2,0;10,-1,7,2,0;60 (proved)
Phone: Settings: Local RTP port: 5004
Phone: Settings: Keep-alive interval: 20 seconds
Phone: Settings: Use NAT IP: <empty>
Phone: Settings: STUN server: <empty>
Phone: Account 1: Account Active: Yes
Phone: Account 1: SIP Server: bluesip.net
Phone: Account 1: Outbound Proxy: <hostname.to.10.xxx.yyy.15>
Phone: Account 1: SIP User ID: <nonnumericBluesipIdent>
Phone: Account 1: Authenticate ID: bluesip/<nonnumericBluesipIdent>
Phone: Account 1: Authenticate Password: <bluesipPassWord>
Phone: Account 1: Name: <givenNameSurName>
Phone: Account 1: Use DNS SRV: Yes
Phone: Account 1: SIP Registration: Yes
Phone: Account 1: Unregister On Reboot: Yes
Phone: Account 1: Register Expiration: 15 minutes
Phone: Account 1: Local SIP port: 5060
Phone: Account 1: SIP Registration Failure Retry Wait Time: 120 seconds (router reboot needs 70 seconds)
Phone: Account 1: NAT Traversal (STUN): No
Phone: Account 1: Send DTMF: via RTP (RFC2833)
Phone: Account 1: SRTP Mode: Disabled
Phone: Account 2: Account Active: Yes
Phone: Account 2: SIP Server: terrasip.net
Phone: Account 2: Outbound Proxy: <hostname.to.10.xxx.yyy.15>
Phone: Account 2: SIP User ID: <numericTerrasipIdent>
Phone: Account 2: Authenticate ID: <numericTerrasipIdent>
Phone: Account 2: Authenticate Password: <terrasipPassWord>
Phone: Account 2: Name: <givenNameSurName>
Phone: Account 2: Use DNS SRV: Yes
Phone: Account 2: SIP Registration: Yes
Phone: Account 2: Unregister On Reboot: Yes
Phone: Account 2: Register Expiration: 15 minutes
Phone: Account 2: Local SIP port: 5062
Phone: Account 2: SIP Registration Failure Retry Wait Time: 120 seconds (router reboot needs 70 seconds)
Phone: Account 2: NAT Traversal (STUN): No
Phone: Account 2: Send DTMF: via RTP (RFC2833)
Phone: Account 2: SRTP Mode: Disabled
Phone: Account 3: Account Active: No
Phone: Account 4: Account Active: Yes
Phone: Account 4: SIP Server: <hostname.to.10.xxx.yyy.15>
Phone: Account 4: Outbound Proxy: <empty>
Phone: Account 4: SIP User ID: <internalPhoneNumber>
Phone: Account 4: Authenticate ID: <internalPhoneNumber>
Phone: Account 4: Authenticate Password: <internalPassWord>
Phone: Account 4: Name: <givenNameSurName>
Phone: Account 4: Use DNS SRV: Yes
Phone: Account 4: SIP Registration: Yes
Phone: Account 4: Unregister On Reboot: Yes
Phone: Account 4: Register Expiration: 15 minutes
Phone: Account 4: Local SIP port: 5066
Phone: Account 4: SIP Registration Failure Retry Wait Time: 120 seconds (router reboot needs 70 seconds)
Phone: Account 4: NAT Traversal (STUN): No
Phone: Account 4: Send DTMF: via RTP (RFC2833)
Phone: Account 4: SRTP Mode: Disabled
Timetable:
At 0257 hours: Phone is switched off ((Register Expiration + 5 minutes) before router reboot)
At 0317 hours: Router reboots
At 0332 hours: Phone is switched on ((DNS TTL + 5 minutes) after router reboot)
Observations:
1. The system behaves as expected at almost all times.
2. The WAN interface traffic shaping seems to work fine.
3. With respect to the audio quality, the Grandstream GXP2010 is very good.
4. The quality of the audible communication suffers extremely, when the router's WLAN interface
gets under load. It seems that the router CPU is too slow to deal with both VoIP and WPA2/AES
key calculations at the same time. Just to know, one of the killer applications for the
current router hardware is to perform an FTP-get on a WLAN-connected client to draw 1 GB
for example, invoking a 100BASE-T-connected server with the router used as the joining
device. Such an activity increases the router's load average to values from 2 through 4,
sometimes to values up to 12, too. Reboots may also happen during such an FTP. The FTP
transfer itself finishes always well and correctly. Without some traffic shaping,
all SIP registration get typically lost in such a way that the phone does not find back
by itself, and has, therefore, always to be rebooted. With traffic shaping as described
above, the provider accounts remain registered, at least, and running talks are not
truncated as long as the router does not reboot. Establishing new talks is not possible
though. One arrives at the conclusion that it will be a good idea to switch WLAN off on
the Milkfish system, and to use a second router hardware running as the WLAN bridge.
Further, it also seems to be cheaper to run two WRT54GL v1.1 instead of one high-performance
system, whereat the two power supplies should be replaced by one part with a high degree of
efficiency. The memory usage table of the current Milkfish system with WLAN here does not
look critically for me.
Total available 13028 kB
Free 6%
Used 94%
Buffers 9%
Cached 46%
Active 32%
Inactive 23%
5. If the communication partner runs Linphone on a notebook connected via UMTS 3G,
the overall communication quality varies between good and unserviceable, whereat
one gains the impression that the codecs PCMU and PCMA give better results then all
the others being available, when the packet loss rate is very high.
6. From the compatibility point of view, Terrasip seems to be an excellent SIP provider.
The Grandstream phone in debug mode yields strings as "TerraSIP Advanced Router 1.0.8"
and "X-Asterisk-HangupCauseCode" (2009-11-12).
7. It is known that Bluesip is a reliable but somewhat delicate provider. In debug mode,
the Grandstream phone shows the string "Sip EXpress router (0.9.7 (i386/linux))" in
Bluesip-related SIP traffic (2009-11-22). The Milkfish proxy running on the router under
DD-WRT is able to register at Bluesip. Further, with the dynamic DNS service of Dyndns
with its short TTL provided, instead of the dynamic service of Dynsip, the presented
VoIP setup seems to function perfectly under normal circumstances of sufficiently small
load. The Bluesip RTP stream issue is definitively solved.
8. Some providers have problems to resolve ENUM entries, some not. Deutsche Telekom resolves,
for example, Bluesip ENUM entries of the form +4989... without any problem. In Germany, one has
to dial 089..., as usual. Vodafone, Arcor, and Bluesip behave similarly. Performing a call to
such an ENUM entry from Spain, operated by Telefónica de España, also works well where one will,
of course, always dial 004989... In this case the question is who manages the call for Telefónica
in Germany, i.e., who does its job par excellence with respect to that topic.
1&1, O2 et cetera also resolve the Bluesip ENUM entries +4989... without difficulty,
whereat some providers need 004989... while others content themselves with 089...
On the other hand, Sipgate is a candidate which often fails to resolve the above ENUM entries.
In many cases, the first try is unsuccessful while a second or third one works. Sipgate seems
to accept both, the 089... and the 004989... dial-in variants (2009-11-12). Furthermore, the
operator in Germany, working for the operator belonging to www.espantel.com, does not perform
queries at all to resolve a Bluesip ENUM entry +4989... in Germany. So, it is seen that ENUM
is still an issue.
9. Next are five selected and anonymized syslog entries as they have been generated by the
Grandstream phone to file the SIP traffic belonging to an incoming call.
a) INVITE sip:{userIdent}@10.xxx.yyy.71:5062;transport=udp SIP/2.0
Record-Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
Record-Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>
Record-Route: <sip:{sipProviderAddressA};ftag={tag1};lr=on>
Via: SIP/2.0/UDP 10.xxx.yyy.15;branch={branch1}
Via: SIP/2.0/UDP {sipProviderAddressA};branch={branch2}
Via: SIP/2.0/UDP {sipProviderAddressB}:5060;branch={branch3};rport=5060
User-Agent: SIP provider PSTN GW
...
b) SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.xxx.yyy.15;branch={branch1}
Via: SIP/2.0/UDP {sipProviderAddressA};branch={branch2}
Via: SIP/2.0/UDP {sipProviderAddressB}:5060;branch={branch3};rport=5060
Record-Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
Record-Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>
Record-Route: <sip:{sipProviderAddressA};ftag={tag1};lr=on>
User-Agent: Grandstream GXP2010 1.2.2.14
...
c) ACK sip:{userIdent}@10.xxx.yyy.71:5062;transport=udp SIP/2.0
Record-Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
Record-Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>
Via: SIP/2.0/UDP 10.xxx.yyy.15;branch=0
Via: SIP/2.0/UDP {sipProviderAddressA};branch=0
Via: SIP/2.0/UDP {sipProviderAddressB}:5060;branch={branch4};rport=5060
Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>,
<sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
User-Agent: SIP provider PSTN GW
...
d) BYE sip:{phoneNumber}@{sipProviderAddressB} SIP/2.0
Via: SIP/2.0/UDP 10.xxx.yyy.71:5062;branch={branch5}
Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>
Route: <sip:{sipProviderAddressA};ftag={tag1};lr=on>
User-Agent: Grandstream GXP2010 1.2.2.14
...
e) SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.xxx.yyy.71:5062;branch={branch5}
Record-Route: <sip:{routrWanAdr};r2=on;ftag={tag2};lr=on>
Record-Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag2};lr=on>
User-Agent: SIP provider PSTN GW
...
Remember, not all the records of the SIP dialogue are filed here, and the records
are truncated somehow. It is seen that in a), b), c), and d) all the lines containing
the substring {routrWanAdr} should better disappear. The Grandstream phone does not
have to know {routrWanAdr}. In e), it seems that anything went wrong. The line
with the substring 10.xxx.yyy.15 should appear before the line with {routrWanAdr}, and,
a question could be where the "200 OK" message has come from. Nevertheless, it seems that
in SIP messages UUCP-style bang paths are applied, being a pity.
The following fragment shows, just as foot for thought, how a brute-force address
substitution could be performed, based on regexps, not too nice, of course.
cat fileNameIn \
| sed -e 's![:=@ ]0*AAA\.0*BBB\.0*CCC\.0*DDD[; :]!{{{{{&}}}}}!g' \
-e 's,{{{{{.,&{{{{{,g' \
-e 's,.}}}}},}}}}}&,g' \
-e 's,{{{{{[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*}}}}},{{{{{aaa.bbb.ccc.ddd}}}}},g' \
-e 's,{{{{{,,g' \
-e 's,}}}}},,g' \
-e 's![:=@ ]0*AAA\.0*BBB\.0*CCC\.0*DDD$!{{{{{&}}}}}!' \
-e 's,{{{{{.,&{{{{{,' \
-e 's,{{{{{[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*}}}}},{{{{{aaa.bbb.ccc.ddd}}}}},' \
-e 's,{{{{{,,g' \
-e 's,}}}}},,' > fileNameOut
AAA.BBB.CCC.DDD and aaa.bbb.ccc.ddd are the two essential IP addresses of the router.
The procedure is quite easy and there is a small risk to forget anything to rewrite.
A. 2009-11-13, 2009-11-15: The following message sequences appeared in the syslog:
/usr/sbin/openser[9999]: ERROR: sip_msg_cloner: cannot allocate memory
/usr/sbin/openser[9999]: ERROR: new_t: out of mem:
/usr/sbin/openser[9999]: ERROR: t_newtran: new_t failed
/usr/sbin/openser[9999]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)
As a consequence, the following Grandstream phone SIP registration attempts failed with 500.
Up to now, the problem appeared never again.
TODO:
1. Setup a second WRT54GL v1.1 as a WLAN AP bridge, allowing to disable WLAN on the main router.
This will probably solve the performance problem described under observation 4, and,
probably the memory problem described under observation A, too.
2. Ask in the forum whether it is believed that there might be any memory leak, or, the Linksys
WRT54GL v1.1 with its 16 MB of RAM is somewhat too small for all that above.
Thu, 26 Nov 2009 21:20:59 +0100
Stephan K.H. Seidl