[SR-Users] Configuring Kamailio as a "VoIP traffic reflector"

[Tahiro Hashizume]

Hi there,

This e-mail is going to be lengthy and I hope you will not get
frustrated (like I am, for different reasons described later) by
reading it all from the beginning to the end since I have just warned
you :P
You have absolutely no need for reading the entire post unless you are
crazy enough read about what I do for fun in given circumstances.

Basically, I would like Kamailio and Asterisk to run on the same box
in such a way that
A.)Asterisk listens on eth0 (on 10.1.1.15/24 with ProxyARP enabled)
for incoming SIP register requests from VoIP-ATAs
B.)Kamailio listens on five IP addresses on dummyN which has
10.1.1.1N/32 (N=0-4, so dummy0 has 10.1.1.10/32, for example) making
five SIP+RTP sessions to the same remote host to appear as if they are
from five different hosts - so that a single instance of Asterisk
running on debian may be registered (through Kamailio) on the same
remote host by using five different accounts and source IP addresses.

I know Asterisk alone cannot do this (even by running multiple
instances of it) and that there have to be five instances of both
SIP-Proxy and RTP-Proxy so that the source address can be literally
spoofed.

Should be simple, but so far cannot find good sources of reference. I
need your advice.

Thanks in advance.



<< Backgrounds - read only if you are curious >>
The so-called frustration is when your needs are not realized due to
technological limitations.
I have years worth of frustration on the VoIP setup at home and that's
totally NOT your fault.

Written below for those who happen to be curious should sound
interesting, so here is the situation I'm facing;

I'm in Japan and our infrastructure is well within the definition of
NGN which in my case includes a low-latency VoIP to replace the
traditional PSTN.
(NTT will end ISDN in 2020, copper-line PSTN in 2025, as announced so far.)

The service is provided by NTT (former state-run telecom) of Japan and
works on FTTH which carries:
a.)PPPoE for those who wish to get IPv4&IPv6 connectivity - which for
the most part is so that users get to choose their favorite ISP.
b.)WAN-reachable IPv6 traffic
c.)WAN-unreachable IPv4 for SIP based services (address blocks
reserved and announced by AS9595)

Given the fact that b.) and c.) are only applicable (optionally and
respectively) to those who signed up for the native-IPv6 (we call it
IPoE, oddly) service and to those who signed up for the VoIP service,
it's essentially an L2 transport service for PPPoE to your ISP - very
much like the way we had our phone-line and ISP (dial-up) separately
signed up for in the old days (hence I call it the access-line
service).

I've made a switch over to VoIP-based PSTN from the copper-line in
April 2011 after seeing that copper-line PSTN served no better in case
of emergency like 3.11 when people want to call others to see if their
loved one are okay - on the evening through the night of March 11
2011, our traditional PSTN stayed at its capacity limits while
VoIP-based means of communication (incl. Skype, surprisingly) stayed
intact. That was the wake-up call.

Now, upon signing up for the VoIP service, the user receives a box so
called HGW (stands for Home Gateway) which is very much a SIP+RTP UA
on its WAN side and SIP+RTP server on LAN side (up to 5 UAs may
register if the UA supports "sip session-timer"). And this HGW is
being the pain that drove me to writing this e-mail - it only allows
one SIP-register per IP address. Further, looking into the specs
requirements for HGW published by NTT (=there's a centralized
documentation for it since the designs and manufacturing of HGW is
split across several companies), there's a part which basically says:
"One SIP register to HGW from a UA on LAN should be able to handle
(but not limited to) one data session. An UA on HGW's LAN side may
support multiple-data session per SIP register(optional)." - which to
me reasonably explains why my HGW only allows one SIP-register per IP
address. My gyess is that the unwritten assumption here is "one sip
register"="one physical phone", which is quite understandable.

Regarding the fact that NTT optionally provides services like:
1.)additional phone numbers
2.)multi-data sessions(RTP for voice, for example)
...on one trunk. This, and also in accordance with the technical
specs. requirements for HGW above means supporting multiple RTP
sessions either terminated or originated by an Asterisk box which sits
on the HGW's LAN side requires that a single instance of Asterisk on a
debian box somehow uses multiple IP addresses (with or without the use
of other software). The simplest way of doing this (to me) seemd like
running five instances of RTP(proxy)+SIP(proxy) which will each listen
on one of five IP addresses, to which the Asterisk instance in
question could establish one session of SIP+RTP each. The idea seemed
simple enough, but there did not seem like good selections of software
years ago. I have once given up on the implementation years ago,
altered the NTT-supplied HGW with a third-party product (NVR500 by
YAMAHA which on its LAN behaves as a MGCP+RTP server) in order to
maximize the stability of the phone system. This was due to the fact
that the x86-box I was using was hardware-unstable and that the HGW's
behavior was something I did not like dealing with (recently solved).
I've decided to make a come-back to Asterisk recently since I recently
started using hylafax running on a RasPi with RS232 modem hooked up to
it but with missing support for CID since the Japanese equivalent of
CID (we call it Number-Display) does not follow the Bellcore standards
and the modem I use only supports Bellcore standards- going VoIP again
and running iaxmodem could solve this issue.

--------------------------------------------
Tahiro Hashizume
Department of Electrical and Electronic Engineering at Tokyo Denki University
5 Senju-Asahi-cho Adachi-ku Tokyo, JP1208551 Japan
--------------------------------------------