Experimental VoIP Setup 1.3 2009-11-29


Changelog 1.2 -> 1.3:
Added a 2nd Linksys WRT54GL v1.1 system as WLAN bridge
Router: Running: Removed WLAN
Router: Wireless: Basic Settings: Wireless Network Mode: Disabled
Added the WLAN bridge setup
Added a WLAN bridge timetable entry
Observation 1: Text changed
Observation 4: Text changed
Observation 7: Text changed
TODO 1: Text changed
TODO 2: 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
Bridge: 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, 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 Network Mode: Disabled
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)
Bridge: WAN connection type: Disabled
Bridge: LAN IP address: Fixed address 10.xxx.yyy.151
Bridge: Running: NTP, WLAN, Syslogd, QoS, HTTP, Cron
Bridge: DDNS: DDNS Service: Disabled
Bridge: Setup: Advanced Routing: Operating Mode: Router
Bridge: Setup: Advanced Routing: Dynamic Routing: Disabled
Bridge: Wireless: Basic Settings: Wireless Mode: AP
Bridge: Wireless: Basic Settings: Wireless Network Mode: G-Only
Bridge: Wireless: Basic Settings: Network Configuration: Bridged
Bridge: Wireless: Wireless Security: Security Mode: WPA2 Personal
Bridge: Wireless: Wireless Security: WPA Algorithms: AES
Bridge: Services: Services: DNSMasq: Disabled
Bridge: Milkfish: Main Switch: Disabled
Bridge: Security: Firewall: SPI Firewall: Disabled
Bridge: NAT/QoS: Static Port Forwarding: None
Bridge: NAT/QoS: UPnP: Off
Bridge: NAT/QoS: QoS: Start QoS: Enabled
Bridge: NAT/QoS: QoS: Port: LAN & WLAN
Bridge: NAT/QoS: QoS: Packet Scheduler: HTB
Bridge: NAT/QoS: QoS: Uplink: 100000 kbps
Bridge: NAT/QoS: QoS: Downlink: 100000 kbps
Bridge: NAT/QoS: QoS: Optimize for Gaming: No
Bridge: NAT/QoS: QoS: Service Priority ntp: Premium
Bridge: NAT/QoS: QoS: Service Priority rtp: Premium
Bridge: NAT/QoS: QoS: Service Priority sip: Premium
Bridge: NAT/QoS: QoS: MAC Priority Grandstream GXP2010 Phone: Premium
Bridge: NAT/QoS: QoS: Ethernet Port Priority Port1 ... Port4: Exempt, 100M
Bridge: Admin: Management: Router Management: Overclocking: 216 MHz
Bridge: Admin: Keep Alive: Schedule Reboot: At a set Time: <bridgeRebootTime> Everyday
Bridge: Admin: Commands: Firewall: <empty>
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 0322 hours: Bridge reboots
At 0332 hours: Phone is switched on ((DNS TTL + 5 minutes) after router reboot)

Observations:
1. The system behaves as expected at all times.
   Many thanks for the great work of all the parties concerned.
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 problem of bad audio quality or malfunction from high router load by traffic of any
   kind seems to be definitively solved. Up to the present, there is no practice-oriented
   traffic scenario, significantly interfering the audible communication. Unscheduled router
   or WLAN bridge reboots have never been seen again. The solution is stable in such a way
   as to permit to no longer switch the phone off. Nevertheless, the strong schedule for phone,
   router, and bridge according to the above timetable is still applied because it is believed
   that daily reboots of router and phone yield higher overall reliability. A dead-time of 37
   minutes between 0257 and 0334 hours can be accepted because outside that interval the phone
   is conventionally operable. The current structure of the experimental setup looks as follows.
                                            LAN
                                          |||||||
            +---------+   +---------+   +-+++++++-+   +---------+
            |         |   |         |   |         |   |         |
     Line---|  Modem  +---+ Router  +---+ Switch  +---+ Bridge  +---WLAN
            |         |   |         |   |         |   |         |
            +---------+   +---------+   +----+----+   +---------+
                                             |
                          +---------+   +----+----+
                          |         |   |         |---
                          |  Phone  +---+ Switch  |---LAN
                          |         |   |         |---
                          +---------+   +---------+
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. 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. Take more bandwidth with Annex M under contract next year.

Sun, 29 Nov 2009 19:29:01 +0100
Stephan K.H. Seidl