1. Router dialog:
I spent a huge amount of time attempting to circumvent this problem via additional routers. I found that this does not appear solvable via routers. What I attempted is the following.
A. NTT router (Router 1) LAN is 192.168.1.1
B. Router 2 WAN is 192.168.1.2 Router 2 LAN is 192.168.2.1
C. eth0 is 192.168.1.3 (on Router 1 LAN)
D. eth1 is 192.168.2.2 (on Router 2 LAN)
However, the registration host remains the NTT router at 192.168.1.1 in both cases and thus, even though eth1 is available, unless I manually bring down eth0, Asterisk will always use eth0 for the registrations. I have not found a way to have the NTT router also have a second address on the 192.168.2 network (say 192.168.2.3) such that trunk 1 could be assigned host 192.168.1.1 forcing Asterisk to use eth0 and trunk 2 assigned host 192.168.2.3 forcing use of eth1. If I could, that would most likely work.
By the way, I tried virtual interfaces as well but same issue as above.
I'm not sure whether running 2 instances of Asterisk on this type of stripped down voip-only box is feasible. These types of devices appear to have some popularity especially among general users with little to low IT abilities.
3. My heart sank a little bit when I read this one:
I don't know that there is a solution already in asterisk, but the bottom
line is code gets written by frustrated programmers. It will be hard to
find someone on this list that is frustrated with this particular problem
because none of us actually have to deal with it. One of NTT's customers
will have to step up to the plate, probably, as I cannot really think of
any other use for this patch. The multipath example perhaps, but anyone
needing that is probably already using routing equipment to solve that
I suppose that is perhaps true for many developers in open source communities - in terms of motivations for enhancements etc. I think there are some instances in open source in general where dev contributors are motivated by other aspects as well. If I had the ability to write and contribute the enhancement, I most certainly would and would be very happy to help other fellow residents here in Japan (I'm American but living here). Of course there are Japanese developers involved in some open source projects (e.g. Linux, apache, etc.) However, it seems that the participation is comparatively low and also English language challenges are a factor. So, I guess I can try to represent those folks too given that this feature would help other current and future Asterisk community people in Japan. It is also possible that the ratio of Asterisk-capable developers to non-capable users in the Japanese Asterisk community may be far lower than in other regions.
Below, I've copied in some replies to which I responded above for reference:
>>> If each trunk is using diferent router IP - you don't need any changes in
>>> Asterisk, but configuring the routing on the machine.
>>> trunk 1 uses src IP 188.8.131.52 on eth0 and router 184.108.40.206
>>> trunk 2 uses src IP 220.127.116.11(but the same as on eth0 will also work) on
>>> and router 18.104.22.168
>>> ip a a dev eth0 22.214.171.124
>>> ip a a dev eth1 126.96.36.199
>>> ip r a 188.8.131.52 dev eth0 src 184.108.40.206
>>> ip r a 220.127.116.11 dev eth1 src 18.104.22.168
>>> with this setup Asterisk will pickup the outgoing IP for each trunk
>> This is true, and you can of course make this dramatically more
>> complicated by adding more physical NICs, or virts on the same system,
>> or ethernet bridging techniques.
> I am guessing this won't help the OP, as he describes registering to the
> device on his network (otherwise the MAC wouldn't matter). There is only
> one of them, and must assume only one IP. There is no way for the routing
> layer to know which MAC should handle the outbound packet, as the
> determining factor is actually in the application layer.
>> I second that you are trying to solve a solveable problem using a much
>> harder approach than what to me and the other poster is the obvious
>> solution already supported by asterisk.
> I don't know that there is a solution already in asterisk, but the bottom
> line is code gets written by frustrated programmers. It will be hard to
> find someone on this list that is frustrated with this particular problem
> because none of us actually have to deal with it. One of NTT's customers
> will have to step up to the plate, probably, as I cannot really think of any
> other use for this patch. The multipath example perhaps, but anyone needing
> that is probably already using routing equipment to solve that issue.
A quick workaround idea:
keep 2 asterisk instances on the box, with second being minimal setup,
using eth1 and forwarding all calls to main instance.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum