Experimental VoIP Setup 1.5 2010-02-11


Changelog 1.4 -> 1.5:
Equipment: Radio added
Router: NAT/QoS: QoS: Optimize for Gaming: No -> Yes
Router: NAT/QoS: QoS: Service Priority sip: Premium -> Express
Router: NAT/QoS: QoS: MAC priority radio added
Bridge: NAT/QoS: QoS: Uplink: 100000 kbps -> 11000 kbps
Bridge: NAT/QoS: QoS: Downlink: 100000 kbps -> 11000 kbps
Bridge: NAT/QoS: QoS: Optimize for Gaming: No -> Yes
Bridge: NAT/QoS: QoS: Service Priority sip: Premium -> Express
Bridge: NAT/QoS: QoS: MAC priority radio added
Observation 2: Text added
Observation 4: Figure completed

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 0.2B, Firmware version 1.2.2.26, Bootloader version 1.1.6.7
Radio: Terratec Noxon Internet Radio For Ipod, Firmware version 3.8.36.6921 (2009-05-08)
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: Yes
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: Express (phone remains registered, even under load)
Router: NAT/QoS: QoS: MAC Priority Grandstream GXP2010 Phone: Premium
Router: NAT/QoS: QoS: MAC Priority Terratec Noxon Internet Radio: Express
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: 11000 kbps
Bridge: NAT/QoS: QoS: Downlink: 11000 kbps
Bridge: NAT/QoS: QoS: Optimize for Gaming: Yes
Bridge: NAT/QoS: QoS: Service Priority ntp: Premium
Bridge: NAT/QoS: QoS: Service Priority rtp: Premium
Bridge: NAT/QoS: QoS: Service Priority sip: Express
Bridge: NAT/QoS: QoS: MAC Priority Grandstream GXP2010 Phone: Premium
Bridge: NAT/QoS: QoS: MAC Priority Terratec Noxon Internet Radio: Express
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. Starting from some "Cold start point", the system at all behaves occasionally as expected.
2. The WAN interface traffic shaping seems to work fine.
   After inserting adequate values for the uplink and downlink rates of the WLAN bridge
   the WLAN interface traffic shaping works fine, too.
   With respect to this point, it seems to be very wise to have two separated systems for
   WAN and WLAN when running Linux because there are two interfaces exhibiting bottleneck
   behavior while the scheduler is obviously prepared to handle only one.
   Two different systems with the right entries ensure that a newly acquired radio representing
   a streaming device is no longer interfered by activities whatsoever of WLAN-connected
   notebooks. Here it should be noted that the radio is somewhat handicapped because of
   its reception conditions. The power consumption of the two Linksys WRT54GL v1.1 devices
   together is less than 5 watt, measured at the 12 volt line.
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 current structure of the experimental
   setup looks as follows.
                                            LAN
                                          |||||||
            +---------+   +---------+   +-+++++++-+   +---------+
            |         |   |         |   |         |   |         |
     Line---|  Modem  +---+ Router  +---+ Switch  +---+ Bridge  +---WLAN
            |         |   |         |   |         |   |         |
            +---------+   +---------+   +----+----+   +---------+
                                             |
                          +---------+   +----+----+
                          |         |   |         |---
                          |  Phone  +---+ Switch  |---LAN
                          |         |   |         |---
                          +---------+   +---------+
                WLAN          WLAN          WLAN          WLAN
                 |             |             |             |
            +----+----+   +----+----+   +----+----+   +----+----+
            |         |   |         |   |         |   |         |
            |    PC   |   |    PC   |   |    PC   |   |  Radio  |
            |         |   |         |   |         |   |         |
            +---------+   +---------+   +---------+   +---------+
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). Next is a frame as it has been sent
   from the Milkfish proxy to Bluesip at a particular time while the traffic has been
   recorded by Bluesip. For the following discussion, it is assumed that, at the same
   time, Terrasip has received analogical frames.
     INVITE sip:{somePhoneNumber}@bluesip.net SIP/2.0
     Record-Route: <sip:{routrWanAdr};r2=on;ftag={tag1};lr=on>
     Record-Route: <sip:10.xxx.yyy.15;r2=on;ftag={tag1};lr=on>
     Via: SIP/2.0/UDP {routrWanAdr};branch={branch1}
     Via: SIP/2.0/UDP 10.xxx.yyy.71:{localSipPort};branch={branch2}
     From: "Stephan Seidl" <sip:<nonnumericBluesipIdent>@bluesip.net>;tag={tag1}
     To: <sip:{somePhoneNumber}@bluesip.net>
     Contact: <sip:<nonnumericBluesipIdent>@{routrWanAdr}:5060;transport=udp>
     ...
     v=0
     o=<nonnumericBluesipIdent> 8000 8001 IN IP4 10.xxx.yyy.71
     s=SIP Call
     c=IN IP4 10.xxx.yyy.71
     t=0 0
     m=audio 5086 RTP/AVP 0 8 4 18 2 97 9 3 101
     a=sendrecv
     a=rtpmap:0 PCMU/8000
     ...
   Since Terrasip always sends the RTP to the right receiver, it can indirectly be
   concluded that Terrasip is so smart to recognize such protocol violations as
   seen above, "IN IP4 10.xxx.yyy.71" being the internal Grandstream IP address,
   and silently replaces the latter by "IN IP4 {routrWanAdr}" where {routrWanAdr}
   is evidently taken from Record-Route information. There are conflicitve opinions
   whether this is a good practice. On the one hand, it works, even with protocol
   violations. On the other hand, protocol errors are never detected, hence never
   fixed. Terrasip takes the freedom to perform maintenance periods of several hours,
   occasionally.
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). Bluesip is a member of the opposite party.
   Their interpreters do not tolerate protocol violations as sending strings as
   "IN IP4 10.xxx.yyy.71", but Bluesip was so kind to perform some traces. At least the
   Milkfish proxy running on the router under DD-WRT is able to register at Bluesip.
   Further, starting from some "Cold start point", it is frequently possible to have phone
   calls with correctly handled RTP streams. But, out of the sky, after a nocturnal router
   reboot with its IP address change, the Grandstream does not get the RTP stream anymore
   while phone calls through the provider Bluesip. At the same time, with Terrasip, the
   talks take normal course. It happens that the phone gets again conventionally operable
   after any router reboot later on, but not too frequently. For a long time it has been
   believed that such a behavior comes from the fact that Bluesip has a DNS cache problem
   in the sense that a SOA TTL information is ignored, but the latter is not the case.
   The performed traces show that not any stale WAN IP address appears as data sometimes,
   but the internal Grandstream IP address, 10.xxx.yyy.71. Such bad states can temporarily
   be repaired feeding "Use NAT IP: {routrWanAdr}" into the phone, but, of course, one cannot
   live with such a solution. Concluding, what was thought of as being a provider DNS cache
   problem is simply emerged as a Milkfish bug. My tip is to look at the code which has to
   convert the Milkfish From-Domain into an IP address. This code might be somewhat too
   weak with respect to timeouts and/or resolver return codes such that the control falls
   through onto quite a bad last resort value, or, there is simply an index bug or
   something similar. Fortunately, things like that are not my turn here. There are two
   points suggesting that the problem comes from such a code sequence. Firstly, nobody
   seems to have that problem so massively like me, but the problem is occasionally
   reported by others, too. And, secondly, I know that the DNS servers I normally use are
   pretty slow.
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 was a candidate which often failed to resolve the above ENUM
   entries. In many cases, the first try was unsuccessful while a second or third one worked.
   Sipgate seems to accept both, the 089... and the 004989... dial-in variants (2009-11-12).
   The operator in Germany, working for the operator belonging to www.espantel.com, does not
   perform queries at all to resolve an ENUM entry +4989... in Germany. And the current
   operator in Germany, working for the operator Jazztel in Spain, exhibits some strange cache
   behavior. Dialling a number belonging to an ENUM entry +4989... for the first time, or
   dialling that number after some months again, the number appears to be busy. From the next
   working day on, all works fine. After some weeks/month of inactivity the operator again needs
   one night to make the service available, i.e., if one needs to have a talk from Spain to
   somebody with an ENUM entry +4989..., it is a good idea dial the number already some days
   before to be sure to have all in cache at the right time. So, it is seen that ENUM is still
   a point, at least, if it is called from foreign countries.
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:{localSipPort};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:{localSipPort};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:{localSipPort};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:{localSipPort};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.
2. To get the installation working deactivate Milkfish and try an ordinary configuration with STUN.

Thu, 11 Feb 2010 22:13:34 +0100
Stephan K.H. Seidl