On Mon, Jul 4, 2011 at 9:58 AM, Michael Picher <[email protected]> wrote:
> Well, technically if you are in a fail-over type situation and you have a
> login type sip trunk provider your login should start using the other route.
> Or, if you use a login type SIP trunk and a static IP type SIP trunk could
> you route the two difference scenarios out different internet connections
> based on destination address with the firewall?  A login type SIP trunk does
> not require you to map traffic.  Actually, that might not work if one of
> those needs a 1:1 nat.  Ok, 2 login type SIP trunks would probably work.
I have two login (register) working. I can simply push a route to the
second trunk using the second wan connection. I forward both wan's to
sipx for the needed ports.
> In fact, with a static IP type SIP trunk you need to do 1:1 nat to an
> outside IP in the firewall...  I don't see how this type of connection would
> work with only a single IP on the sipXecs box...  that brings up the whole
> multiple network card type problem.
Again, I am simply talking about remote users. As I said, I don't
think trunking is my issue. I have trunking failing over to each other
as well.

In server behind nat, there is room for only a single IP address. If
this were a trunking issue, I would be asking to provide a field/drop
down in the trunk to pick which IP it uses to connect out.

I think with HA and Mongo, these Ip's (server behind nat) need to be
assumed by the HA role, not by a "server". I think at the same time,
there might be room for improvements for remote user failover without
HA.
> Mike
> On Mon, Jul 4, 2011 at 9:50 AM, Tony Graziano <[email protected]>
> wrote:
>>
>> Right, but my use case was a simple system with dual wan. Seems like a
>> lot to go through (second sipx install or sbc install) to use a second
>> wan port fully, and it only affects remote users.
>>
>> On Mon, Jul 4, 2011 at 9:44 AM, Michael Picher <[email protected]> wrote:
>> > I think it's a good thing to think about but you could possibly use
>> > sipXbridge as well as a third party SBC to do the same thing (or two
>> > third
>> > party SBC's of course).
>> > I'm just sayin, if the SIP trunks are that important off-board SBC's are
>> > a
>> > good idea anyway.
>> >
>> > Mike
>> >
>> > On Mon, Jul 4, 2011 at 8:26 AM, Tony Graziano
>> > <[email protected]>
>> > wrote:
>> >>
>> >> Does it make sense to look at being able to provide more than one IP
>> >> in this field at some point in the future? Use case is as follows:
>> >>
>> >> Firewall with dual WAN. Sip trunk registers out each WAN, successfully
>> >> registers and places, receives calls. One trunk can fail to the other
>> >> trunk.
>> >>
>> >> Remote users successfully register, but cannot load balance or
>> >> failover to second WAN since the server behind nat would have to be
>> >> changed/services restarted in order to fully utilize dual wan's.
>> >>
>> >> It is very customary for us to use multiple providers in a small
>> >> business setup. We simply find that putting up a second instance of
>> >> sipx "only" for this is sometimes more involved than it should be.
>> >>
>> >> Server behind NAT: primary public IP 1.2.3.4, secondary public IP
>> >> 2.3.4.5
>> >>
>> >> I might also suspect with mongo this could be shared/replicated as a
>> >> pool between multiple servers.
>> >>
>> >> Does this make sense to discuss and look at an enhancement request to
>> >> anyone besides me?
>> >>
>> >> --
>> >> ======================
>> >> Tony Graziano, Manager
>> >> Telephone: 434.984.8430
>> >> sip: [email protected]
>> >> Fax: 434.326.5325
>> >>
>> >> Email: [email protected]
>> >>
>> >> LAN/Telephony/Security and Control Systems Helpdesk:
>> >> Telephone: 434.984.8426
>> >> sip: [email protected]
>> >>
>> >> Helpdesk Contract Customers:
>> >> http://support.myitdepartment.net
>> >> Blog:
>> >> http://blog.myitdepartment.net
>> >>
>> >> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
>> >> _______________________________________________
>> >> sipx-dev mailing list
>> >> [email protected]
>> >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>> >
>> >
>> >
>> > --
>> > Michael Picher
>> > eZuce
>> > Director of Technical Services
>> > O.978-296-1005 X2015
>> > M.207-956-0262
>> > @mpicher <http://twitter.com/mpicher>
>> > www.ezuce.com
>> >
>> >
>> > _______________________________________________
>> > sipx-dev mailing list
>> > [email protected]
>> > List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>> >
>>
>>
>>
>> --
>> ======================
>> Tony Graziano, Manager
>> Telephone: 434.984.8430
>> sip: [email protected]
>> Fax: 434.326.5325
>>
>> Email: [email protected]
>>
>> LAN/Telephony/Security and Control Systems Helpdesk:
>> Telephone: 434.984.8426
>> sip: [email protected]
>>
>> Helpdesk Contract Customers:
>> http://support.myitdepartment.net
>> Blog:
>> http://blog.myitdepartment.net
>>
>> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
>> _______________________________________________
>> sipx-dev mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>
>
>
> --
> Michael Picher
> eZuce
> Director of Technical Services
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> www.ezuce.com
>
>
> _______________________________________________
> sipx-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>



-- 
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected]
Fax: 434.326.5325

Email: [email protected]

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected]

Helpdesk Contract Customers:
http://support.myitdepartment.net
Blog:
http://blog.myitdepartment.net

Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

Reply via email to