DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== EON-Highspeed: VoIP Access ======

Connecting to EON's VoIP service via the dedicate VLAN ID 232 seems trivial
and, frankly, using the typical Fritz!Box home router, it pretty much is. There
are a few pitfalls though when attempting the same using a custom Linux router.

===== Provided Credentials =====

This is the (anonymized) info published by the provider in manuals and customer
portal:

^ VLAN ID | 232 |
^ SIP Number | 012345678901 |
^ SIP Password | LongRandomPass |
^ Domain | sip.rfn.de |
^ Proxy Server | 10.199.27.11 |
^ Registrar Server | sip.rfn.de |

EON provides sets of these for each provided number, though actually just the
number changes and passwords typically remain identical.

===== Asterisk Configuration =====

Thanks to PJSip's Wizard module, a very brief configuration is sufficient (the
devil's in the details, though). First of all, //pjsip.conf// must define a transport:

<file ini /etc/asterisk/pjsip.conf>
[global]
type=global
;debug=yes 

[system-udp]
type=transport 
protocol=udp
bind=0.0.0.0
</file>

Anything else goes into //pjsip_wizard.conf//. A dedicated section per provided
SIP number is needed, using a template avoids too much repetition:

<file ini /etc/asterisk/pjsip_wizard.conf>
[eon-highspeed](!)
type = wizard
sends_auth = yes
sends_registrations = yes
transport = system-udp
remote_hosts = sip.rfn.de
endpoint/allow = !all,alaw,g722
endpoint/context = extern
endpoint/direct_media = no
outbound_proxy = sip:10.199.27.11\;lr

[5678901](eon-highspeed)
outbound_auth/username = 012345678901
outbound_auth/password = LongRandomPass
</file>

A few remarks:
  * ''eon-highspeed'' is the template, ''5678901'' a first section "implementing" it
  * Setting ''endpoint/direct_media'' to ''no'' prevents uni-directional communication errors as otherwise the local and remote SIP peers try to establish a direct connection (which fails due to NAT)
  * The ''\;lr'' gibberish which seems to follow ''outbound_proxy'' is crucial, it requests "loose routing" and when missing the request URI is incorrectly constructed (leading to 404 errors). The backslash escapes the semi-colon which otherwise starts a comment

===== Network Setup =====

Here the fun begins: Creating a VLAN interface for ID 232 is trivial, a DHCP
server on that VLAN serves an IP address and a default route. But the system
has a default route already, namely the one received via DHCP on the "regular"
VLAN ID 132!

One could "hack around" this problem by denying the extra default route and
instead add a host route for the proxy IP address via the new default route's
address. While the proxy address is well-known, the new default route may in
theory change at any time. Worst: RTP peers communicated via SIP messages are
arbitrary yet reachable via VLAN 232 only. At least the latter effectively
kills this workaround.

The "proper" solution is to accept the extra default route and reserve it for
Asterisk alone. One way to achieve this is via policy routing and a UID-based
routing rule - assuming that Asterisk runs under its own UID, which is advisable
anyway.

The setup anchors around a dedicated routing table which will receive the
routes from DHCP and serve as the Asterisk user's main table. One may just use a
free number, but for transparency's sake assign it a name in //rt_tables//
(maybe copy default contents from ///usr/share/iproute2/rt_tables// first):

<file shell /etc/iproute2/rt_tables>
232		voip
</file>

**Note: The following is distribution-specific, so anyone not using NetworkManager may have to adjust as needed.**

To add received routes to the new table 232, modify the connection in
NetworkManager (''wan0.232'' is the VLAN-interface's name on my box):

  nmcli c modify wan0.232 ipv4.route-table 232

The routing rule for Asterisk's UID (981 in my case) will be added by the
LAN-connection since that is expected to be more permanent (although it's
arbitrary in theory):

  nmcli c modify lan0.static ipv4.routing-rules "uidrange 981-981 table 232"

Now there's only one issue remaining: Asterisk won't have access to the host's
main routing table anymore and therefore would try to reach local hosts via VLAN
232, too. I chose to solve this via a static route added by the LAN connection
(with 192.168.1.0/24 being the LAN network):

  nmcli c modify lan0.static ipv4.routes "192.168.1.0/24 0.0.0.0 table=232"

===== Final Validation =====

If everything went right:

  * ''ip route show'' will list a single default route via VLAN ID 132
  * ''ip rule show'' will print a lookup rule for uid(range) 981(-981) and table ''voip''
  * ''ip route show table voip'' will list a (single) default route via VLAN ID 232 and a local route for the LAN network on the respective LAN interface
  * Asterisk registers outbound via VLAN ID 232, accepts registrations from LAN hosts (extra config steps needed) and RTP traffic for established calls flows in both directions between VLAN ID 232 and LAN.