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

Sat May 30 02:23:12 CDT 2009

On Sat, 30 May 2009 09:27:55 +0900, JwexlerAt MailDotCom wrote
> 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.

have you tried using NAT? i.e. set the second trunk to 192.168.2.3 (with
nat=allways) and then nat it to 192.168.1.1 in POSTROUTING - this way asterisk
will pickup the second interface and route the packets there before
destination is changed.

if you have 'string' match in iptables and 'ROUTE' target (or mark then use a
rule) it is still possible to do this outside of Asterisk.

Disclaimer : These are workaround suggestions. I agree that having bindadress
for peers is the way to go and will be good addition to Asterisk.

> 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
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev