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 --------------------------------------------
On Wed, Mar 29, 2017 at 09:57:02PM +0900, Tahiro Hashizume wrote:
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.
...
Should be simple, but so far cannot find good sources of reference. I need your advice.
...
Snipping your long story, summarized to: sipserver only accepts 1 connection from 1 ipadress (which is kind of strange, have you tried 1 ipaddress and different source ports?) and you want to make multiple from 1 machine (with multiple ipadresses).
If my understanding is correct the solution is simple, in kamailio use force_send_socket to send requests to the sipserver from different adresses (10.1.1.1N).
The hard part is how you will differentiate the REGISTERS from asterisk to the sipserver. The easiest way I can think of right now is to listen on multiple ports with kamailio and tell the kamailio peers to connect to these in a unique way.
So in kamailio it would something like: if($Rp=="5070") { force_send_socket(10.0.1.10:5060); } else if($Rp=="5071") { force_send_socket(10.0.1.11:5060); } else if(...)
... route(RELAY);
To all and Daniel
have you tried 1 ipaddress and different source ports?
I have not tried it myself, however folks here having the same issue have tried using both "chan_sip" and "pjsip" working on different ports of the same machine (both under control of a single Asterisk instance) and reported that there was no success - only one of the two accounts was successful on register.
If my understanding is correct the solution is simple, in kamailio use force_send_socket to send requests to the sipserver from different adresses (10.1.1.1N).
Yes, that's precisely what I was looking for!
The hard part is how you will differentiate the REGISTERS from asterisk to the sipserver.
The imaginary solution to this in my head is telling Kamailio to listen to 10.1.1.1N:5061 (N=0-4) on dummyN as well, to which Asterisk can register by using"register => 1N@ntt-east.ne.jp:<PASSWD>:001N@10.1.1.1N:5061/<EXTL_TELNUM>"
P.S.-For those who might question, the purpose of using dummyN and enabling ProxyARP on eth0 instead of adding eth0:N is to make the reconfiguration easy when addressing plan changes (which has regularly occurred in my experimental setup).
On Fri, Mar 31, 2017 at 01:15:58PM +0900, Tahiro Hashizume wrote:
The hard part is how you will differentiate the REGISTERS from asterisk to the sipserver.
The imaginary solution to this in my head is telling Kamailio to listen to 10.1.1.1N:5061 (N=0-4) on dummyN as well, to which Asterisk can register by using"register => 1N@ntt-east.ne.jp:<PASSWD>:001N@10.1.1.1N:5061/<EXTL_TELNUM>"
Even simpler, didn't think of just sending to differenct ipadresses. So just set the forced ip to sip:$Ri:$Rp. If you use $fs instead of the old force_send_socket() it is as simple as: $fs="sip:$Ri:$Rp".
Even simpler, didn't think of just sending to differenct ipadresses. So just set the forced ip to sip:$Ri:$Rp. If you use $fs instead of the old force_send_socket() it is as simple as: $fs="sip:$Ri:$Rp".
Well, that and also the SIP-URI as the potential identifier, I thought. Which is neater?