[asterisk-dev] Feature request: Ability to assign which nic card or mac address to use for each trunk in sip.conf

Fri May 29 19:27:55 CDT 2009

I just realized that my email provider flagged several of the replies as spam and thus I am belated in replying to some folks. Apologies. I am now keeping a watch at http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg37783.html to ensure I can respond timely and am in Japan thus the time difference.

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.

2. Two Asterisk instances on the same box consideration:
I am using the following voip device: IP08 by atcom.cn
http://www.atcom.cn/En_products_IP08.htm
It uses a pretty stripped down linux distro called Blackfin Asterisk Package System (BAPs). The following link is to an older model (IP04) and displays an older version of Asterisk but it shows the look/feel of the device and os:
http://www.rowetel.com/ucasterisk/baps.html
http://www.rowetel.com/ucasterisk/ip04.html

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
>issue.
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.
>>>>
>>>> Example:
>>>>  trunk 1 uses src IP 1.1.1.1 on eth0 and router 2.2.2.2
>>>>  trunk 2 uses src IP 1.1.1.2(but the same as on eth0 will also work) on
>>>> eth1
>>>> and router 2.2.2.3
>>>>
>>>> ip a a dev eth0 1.1.1.1
>>>> ip a a dev eth1 1.1.1.2
>>>> ip r a 2.2.2.2 dev eth0 src 1.1.1.1
>>>> ip r a 2.2.2.3 dev eth1 src 1.1.1.2
>>>>
>>>> with this setup Asterisk will pickup the outgoing IP for each trunk
>>>> properly
>>>
>>> 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.

=
Russia Visas: Ukraine and Belarus Visas
Visa and hotels service for Russia, Ukraine, Belarus. Tourist visas. Business visas for Russia. Multi-entry visas Russia. Online hotels. Instant reservations. UK office.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=ed3378004df3e951014d9661aace9c3a