Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

Rick,

This is great info/news!  Thanks for taking the time to research and clarify.  
My concern wasn't even with security so much as having the ability to take our 
destiny into our own hands without the need for hand-holding every step of the 
way, and needing to make sure that schedules always mesh between our engineers 
and yours every time we want to commission a new base station.  But you raise 
some good points, and it is also good to know that there isn't a universal 
backdoor that we need to worry about possibly being discovered and exploited by 
a malicious third-party.

Thanks again,

-- Nathan

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Rick Harnish
Sent: Monday, June 27, 2016 8:40 AM
To: 'WISPA General List'
Subject: Re: [WISPA] Baicells - who's deployed it?

I just got some additional information from Jesse Rausch.  It appears to be 
resolved.

Jesse:  You can simply change one parameter to use your own core.  MME IP is a 
web GUI parameter. An operator can change this to connect a Baicells eNB to a 
third party EPC. No remote programming is necessary for this.  If you want to 
disable the local breakout to use the EPC's PGW, then you can configure a 
parameter in the CLI for this, which everyone has access to.  Some customer may 
be sensitive to the fact that it is possible for technical employees of 
Baicells to remotely access their equipment. All customer radios have an IPsec 
tunnel to our cloud EPC. Because of this, I can remote into our cloud EPC, and 
from there, SSH into the client radio. It is recommended to change the default 
password on the eNB. This comes in very handy and I will at that point ask the 
customer for their password. For the duration of the trial, we will most likely 
keep ports open across the IPsec tunnel to make remote support easier.  After 
the trials, we will most likely recommend all ports be closed except for a port 
for technical support to login to the eNB if necessary.

Respectfully,

Rick Harnish
Director of WISP Markets
Baicells Technologies, N.A.I
Mobile: +1.972.922.1443
Email: rick.harn...@baicells.com<mailto:rick.harn...@baicells.com>
Follow us on Facebook for the latest news<https://www.facebook.com/BaiCells>

From: wireless-boun...@wispa.org<mailto:wireless-boun...@wispa.org> 
[mailto:wireless-boun...@wispa.org] On Behalf Of Rick Harnish
Sent: Monday, June 27, 2016 10:52 AM
To: 'WISPA General List' <wireless@wispa.org<mailto:wireless@wispa.org>>
Subject: Re: [WISPA] Baicells - who's deployed it?

Nathan,

Network security is very important to us.  We are working on developing a 
secure channel to operators to enable operators to change  ENB settings to flow 
to your own PGW.   We will let everyone know when we have this accomplished.  
Until then, our technical staff will need to do this in the interim.  It is a 
temporary limitation.  Thank you for pointing this out.

Respectfully,

Rick Harnish
Director of WISP Markets
Baicells Technologies, N.A.
Mobile: +1.972.922.1443
Email: rick.harn...@baicells.com<mailto:rick.harn...@baicells.com>
Follow us on Facebook for the latest news<https://www.facebook.com/BaiCells>

From: wireless-boun...@wispa.org<mailto:wireless-boun...@wispa.org> 
[mailto:wireless-boun...@wispa.org] On Behalf Of Nathan Anderson
Sent: Sunday, June 26, 2016 3:12 AM
To: WISPA General List <wireless@wispa.org<mailto:wireless@wispa.org>>
Subject: Re: [WISPA] Baicells - who's deployed it?

There has been a lot of talk about network performance both just by itself as 
well as compared to other products, but one thing I would be interested in 
hearing more discussion on -- assuming Baicells allows for it at this point -- 
is the configuration and management interface(s).  Perhaps these UIs are in too 
embryonic a form currently for a productive discussion or a fair analysis to 
take place, and Baicells may be trying to concentrate this phase of the trial 
more on correct MAC function and performance.  But as somebody who is intrigued 
by the idea of running a few of these side-by-side with a competing product on 
a heterogeneous (vendor-wise) 3GPP network with our own core, it would be good 
to know what we are up against as far as ongoing monitoring and maintenance 
goes, since it's presumably a given that we aren't going to be able to use our 
existing vendor's NMS (for example) to monitor and control these.  Sooo...what 
does management look like at this point, what kinds of stats can you collect, 
and what mechanisms can you use to extract and collect them?  Do operators 
using these ENBs feel somewhat blind at this point or are you able to track all 
of the performance indicators that you feel you need in order to be able to 
diagnose issues?

As far as commissioning one of these ENBs goes, I would also be interested to 
know more about what that entails, especially given the claim of "4G Easy as 
WiFi."  So what does

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

There has been a lot of talk about network performance both just by itself as 
well as compared to other products, but one thing I would be interested in 
hearing more discussion on -- assuming Baicells allows for it at this point -- 
is the configuration and management interface(s).  Perhaps these UIs are in too 
embryonic a form currently for a productive discussion or a fair analysis to 
take place, and Baicells may be trying to concentrate this phase of the trial 
more on correct MAC function and performance.  But as somebody who is intrigued 
by the idea of running a few of these side-by-side with a competing product on 
a heterogeneous (vendor-wise) 3GPP network with our own core, it would be good 
to know what we are up against as far as ongoing monitoring and maintenance 
goes, since it's presumably a given that we aren't going to be able to use our 
existing vendor's NMS (for example) to monitor and control these.  Sooo...what 
does management look like at this point, what kinds of stats can you collect, 
and what mechanisms can you use to extract and collect them?  Do operators 
using these ENBs feel somewhat blind at this point or are you able to track all 
of the performance indicators that you feel you need in order to be able to 
diagnose issues?

As far as commissioning one of these ENBs goes, I would also be interested to 
know more about what that entails, especially given the claim of "4G Easy as 
WiFi."  So what does that mean in practice, exactly?  I admit I was a little 
disheartened to hear that at this point, in order to configure an ENB to send 
traffic to your own PGW, a Baicells engineer apparently has to remote into the 
thing to make the change for you.  I'm hoping that this is a temporary 
limitation while they continue to work on the (beta) software and that this 
isn't a permanent state of affairs or indicative of the direction they are 
going, because as Patrick himself said during his ISP Radio interview, "we all 
like to drive our own cars."  The goal of simplicity is a great one from both a 
"customer sat" and support perspective, so long as while you are chasing it you 
don't abandon or significantly hamper flexibility, restrict freedoms, and/or 
increase one's dependence on a third-party for every little thing.

-- Nathan

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Josh Luthman
Sent: Friday, June 17, 2016 12:09 PM
To: a...@afmug.com; WISPA General List
Subject: [WISPA] Baicells - who's deployed it?

Does anyone besides the guys in Amarillo have this gear deployed?  Care to 
comment on/off list?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

Here is the direct link to the offset in the ISP Radio interview where Baicells 
SDR claim is laid to rest: https://www.youtube.com/watch?v=wzXaLsN1yWc=3059

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of Fred 
Goldstein [f...@interisle.net]
Sent: Sunday, June 19, 2016 8:10 PM
To: wireless@wispa.org
Subject: Re: [WISPA] Baicells - who's deployed it?

On 6/19/2016 10:09 PM, Nathan Anderson wrote:
> I believe that Patrick has said as much (not SDR) on the ISP Radio interview 
> with him back in April.  Would certainly go a ways to explaining how they 
> managed to offer it for basically 1/3rd the price of competing gear.

I only know what's public including what was said on the very good WISP
Brothers interview from WISPAmerica. What I got from that is that
Baicells uses Qualcomm chips. So just as Ubiquiti used Atheros chips to
make decent cheap radios, Baicells uses Qualcomm's chips rather than
building everything from scratch. I'm not sure if this applies to all of
their eNBs or just the little one, though. And whether the chip counts
as SDR is itself an interesting question.

> -- Nathan
> 
> From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
> Matt Hoppes [mattli...@rivervalleyinternet.net]
> Sent: Sunday, June 19, 2016 2:19 PM
> To: WISPA General List
> Subject: Re: [WISPA] Baicells - who's deployed it?
>
> I think Adair said he has?
>
> Who says the baicells isn't SDR?  I don't know.


--
Fred Goldsteink1iof...@interisle.net
Interisle Consulting Group
+1 617 795 2701
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

What is Baicells UE default MTU?

I am not sure if all of the Telrad devices on the network (Compact & Breezeway) 
properly support jumbo frames.  I can't remember which device it was -- I 
*think* it was the Breezeway -- but there was one I remember testing and found 
a hard MTU limit on (IIRC, with the current 6.5 GA release, I think a 1496 MTU 
is forced on the PDN service interface VLAN).

Ah, yes, here we go:

eth1.13   Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
  inet addr:NNN.NNN.NNN.NNN  Bcast:NNN.NNN.NNN.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1496  Metric:1

It makes sense to have a default MTU < 1500 on UEs since it is by no means 
guaranteed that the network itself will have the necessary headroom for 1500 
once all of the GTP overhead is accounted for.

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
Matthew Carpenter [mcarpen...@amarillowireless.net]
Sent: Sunday, June 19, 2016 3:59 PM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

Hi,

Yes, the current Biacells (11db) UE when using a Telrad SIM card will connect 
to the Telrad eNB and Telrad core and work fine.
The only issue I have found is that I have to set the Biacells UE’s MTU setting 
down to 1400 for it to work correctly.

The latest firmware from Telrad was supposed to allow MTU of 1500 on the UE, 
but we have not been able to make that work yet.
I am going to send all the details off to Telrad on the MTU issue.  The current 
UE 7000 has a MTU of 1400 by default!

Will test the Biacells (19.5db) as soon as I get it on Monday.


Matt Carpenter




On Jun 19, 2016, at 5:55 PM, Jeremy Austin 
> wrote:


On Sun, Jun 19, 2016 at 2:49 PM, Matthew Carpenter 
> wrote:

The Biacells SIM cards will only authenticate with the Biacells Core.  We were 
not given keys for those SIMs from Biacells.
A Biacells SIM card will boot up with a Telrad 7000 UE and connect to a 
Biacells eNB and Biacells Core.

How about the reverse? A Telrad SIM in a Baicells UE, connecting to a Telrad 
ENB/EPC? I remember some discussion about WISPA about the attractiveness of a 
cheaper UE.

Then again, the next gen Telrad CPEs are ostensibly cheaper than the 7000s...

Thanks for all the compatibility testing, Amarillo -- great work.


--
Jeremy Austin

(907) 895-2311
(907) 803-5422
jhaus...@gmail.com

Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC

Schedule a meeting: http://doodle.com/jermudgeon
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

Okay, cool, so if one intermixes Baicells and Telrad on a network with their 
own core, one can unify the experience across the line for their customers; 
good.

The *eNB* is NATting?  With no option to turn off if using local breakout?  
(Not that I guess it matters if planning to use one's own core.)

I had not considered that since Baicells runs the core that their SIMs are 
pre-populated into that they likely don't give you the keys.  Makes sense.

Many thanks,

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
Matthew Carpenter [mcarpen...@amarillowireless.net]
Sent: Sunday, June 19, 2016 3:49 PM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

The Biacells eNB can be changed to send all customer traffic to the core, or 
you can send customer traffic to it's local Gateway.
We have not tried sending all the customer traffic from a Biacells eNB to our 
Telrad core, but it is something I want to test out.

The Biacells eNB has NAT turned on for customer traffic when using its local 
Gateway.

Currently Telrad does not support peeling off customer traffic and sending to 
the its local Gateway.. it all have to go to the Core.

The Biacells SIM cards will only authenticate with the Biacells Core.  We were 
not given keys for those SIMs from Biacells.
A Biacells SIM card will boot up with a Telrad 7000 UE and connect to a 
Biacells eNB and Biacells Core.



Matt Carpenter




On Sun, Jun 19, 2016 at 4:20 PM, Matt Hoppes 
<mattli...@rivervalleyinternet.net<mailto:mattli...@rivervalleyinternet.net>> 
wrote:
Local offloading is a standard LTE feature. You do need an a device to do it, 
which in guessing Bai has built into their eNB.

> On Jun 19, 2016, at 17:07, Nathan Anderson 
> <nath...@fsr.com<mailto:nath...@fsr.com>> wrote:
>
> So it sounds like you have made Baicells eNB talk to a Breezeway for 
> authentication.  Very cool.
>
> Re: VPLS, I could be wrong (and I haven't actually tried VPLS/VPWS on 
> Telrad), but I don't believe the eNB has anything whatsoever to do with 
> making that work.  As far as it is concerned, it is just passing user 
> traffic.  In the Telrad scenario, I *think* the UE constructs a GRE tunnel to 
> the EPC.
>
> However, the fact that you say that the Baicells eNB does not send user 
> traffic to the core but only authenticates against the core might throw a 
> monkey wrench into that whole theory.  For Telrad VPLS to work, you need a 
> Telrad UE and a Telrad core, and the user traffic clearly needs to go to/from 
> the core for that to work.
>
> How does having the eNB send user traffic directly to your gateway even 
> work?? I mean, that makes sense as long as they can get away with it, because 
> I think it would be a nightmare, both from the service provider's perspective 
> as well as from Baicells' perspective, to have to carry all of the user 
> traffic to the cloud and back, but I thought LTE *required* that user traffic 
> be tunneled via GTP to the core. Does the Baicells eNB implement part of the 
> EPC (likely the SGW and PGW bits) itself?  If you wanted to, could you elect 
> to shut those off and have it ship user traffic off to an external EPC as 
> well?
>
> What do you do for SIM cards with Baicells UEs?  Does Baicells provide those 
> as well?  Have you tried a Baicells SIM in a Telrad UE and vice-versa?
>
> -- Nathan
> 
> From: wireless-boun...@wispa.org<mailto:wireless-boun...@wispa.org> 
> [wireless-boun...@wispa.org<mailto:wireless-boun...@wispa.org>] On Behalf Of 
> Matthew Carpenter 
> [mcarpen...@amarillowireless.net<mailto:mcarpen...@amarillowireless.net>]
> Sent: Sunday, June 19, 2016 11:37 AM
> To: WISPA General List
> Subject: Re: [WISPA] Baicells - who's deployed it?
>
> So far I am have able to mix and match the Biacell, and Telrad eNBs and UEs.
>
> Biacell eNB connects to the core with 0 setup.
> With only one change it will connect and work with the Telrad core.
>
> UEs from both Telrad and Biacells work with either eNBs.
>
> Things to test:
> 1. VPLS from the Telrad Core to the Biacells UE using a Telrad eNB
> 2. VPLS from the Telrad  Core to the Biacells UE using a Biacells eNB (I 
> don't believe this will work. There are some updates to the Biacells eNB 
> coming out soon to add VPLS)
> 3. Does the Biacells UE support VPLS ?
> 4. Does the Biacells UE allow remote management from the Wireless side?
> 5. Do all this again with the new 19.5 dB Biscells UE.
>
> One cool thing is when the Biacells eNB is using the Telrad core it only send 
> SIM card authorization to the core.  All customer data goes out to its 
> gateway and not to the core.
>
> Matthew Carpenter
> Amar

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

I believe that Patrick has said as much (not SDR) on the ISP Radio interview 
with him back in April.  Would certainly go a ways to explaining how they 
managed to offer it for basically 1/3rd the price of competing gear.

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of Matt 
Hoppes [mattli...@rivervalleyinternet.net]
Sent: Sunday, June 19, 2016 2:19 PM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

I think Adair said he has?

Who says the baicells isn't SDR?  I don't know.

> On Jun 19, 2016, at 16:55, Nathan Anderson <nath...@fsr.com> wrote:
>
> Yeah, if you're already buying Telrad Compacts then you *probably* have a 
> Telrad core, so I don't see the appeal of hooking up Telrad eNB to Baicells 
> cloud core.
>
> But the idea of hooking up a Baicells eNB to a Telrad core is interesting, 
> considering the eNB price differential...use Compacts in areas where you are 
> counting on the future SDR roadmap/upgradeability and the extra oomph, and 
> Baicells for little micro-cell sites where you simply aren't going to have 
> high subscriber density or demand and couldn't have justified a Compact to 
> begin with.  Have you actually tried pointing Baicells eNB at a Breezeway?
>
> -- Nathan
> 
> From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
> Adair Winter [ada...@amarillowireless.net]
> Sent: Sunday, June 19, 2016 9:57 AM
> To: WISPA General List
> Subject: Re: [WISPA] Baicells - who's deployed it?
>
> probably possible but since it makes some sort of ipsec connection to their 
> hosted core, it would be more difficult.
>
> The other way around works great though.
>
> On Sun, Jun 19, 2016 at 11:53 AM, Matt Hoppes 
> <mattli...@rivervalleyinternet.net<mailto:mattli...@rivervalleyinternet.net>> 
> wrote:
> Since LTE is a standard  I wonder if you could hook a Telrad eNB to the 
> baicells EPC??
>
> *gear spinning*
>
> On Jun 19, 2016, at 12:20, Adair Winter 
> <ada...@amarillowireless.net<mailto:ada...@amarillowireless.net>> wrote:
>
> Baicells is going to have cheaper hardware but there will be some trade offs 
> to other vendors.
> for example, no 4x4, do dual carrier, etc.
> Also you'll pay per user per month to use their core unless you already have 
> one. so look at the long term when pricing.
>
> On Sun, Jun 19, 2016 at 11:19 AM, Josh Luthman 
> <j...@imaginenetworksllc.com<mailto:j...@imaginenetworksllc.com>> wrote:
>
> Baicells referred me to a distributor for pricing.  I asked last week.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Jun 19, 2016 12:18 PM, "Matt Hoppes" 
> <mattli...@rivervalleyinternet.net<mailto:mattli...@rivervalleyinternet.net>> 
> wrote:
> I've said too much. I haven't said enough.
>
> Ask Patrick for more details on pricing.
>
> On Jun 19, 2016, at 11:59, CBB - Jay Fuller 
> <par...@cyberbroadband.net<mailto:par...@cyberbroadband.net>> wrote:
>
>
> He said "real" good ;)
>
> - Original Message -
> From: Matt Hoppes<mailto:mattli...@rivervalleyinternet.net>
> To: WISPA General List<mailto:wireless@wispa.org>
> Sent: Saturday, June 18, 2016 7:18 AM
> Subject: Re: [WISPA] Baicells - who's deployed it?
>
> As opposed to bad? :P.
>
> On Jun 18, 2016, at 08:03, Josh Luthman 
> <j...@imaginenetworksllc.com<mailto:j...@imaginenetworksllc.com>> wrote:
>
>
> "Good"?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Jun 18, 2016 8:02 AM, "Matt Hoppes" 
> <mattli...@rivervalleyinternet.net<mailto:mattli...@rivervalleyinternet.net>> 
> wrote:
> True. It's good though. Real good.
>
> On Jun 18, 2016, at 02:24, Chris Ruschmann 
> <ch...@scsalaska.net<mailto:ch...@scsalaska.net>> wrote:
>
>
> We all had to sign an NDA. So I'll let the baicells guys answer that one.
>
> On Jun 17, 2016 9:05 PM, <mike.l...@gmail.com<mailto:mike.l...@gmail.com>> 
> wrote:
> Whats the pricing like?
>
> On Jun 17, 2016, at 19:12, Matt Hoppes 
> <mattli...@rivervalleyinternet.net<mailto:mattli...@rivervalleyinternet.net>> 
> wrote:
>
> https://www.facebook.com/thewirelessninja/videos/1017353051688688/
>
> On Jun 17, 2016, at 21:07, Christian Palecek 
> <christ...@cybernet1.com<mailto:christ...@cybernet1.com>> wrote:
>
> Ours*  brain fart.
>
> We are deploying in one o

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

>From my reading, it seems that this is called "local breakout".  And all it 
>means (I think) is that UEs roaming on a foreign network won't have their 
>traffic tunneled all the way back to their provider's PGW, but can instead 
>have it terminated on the foreign provider's PGW.  I'm sure that this 
>flexibility in PGW assignment could be used by vendors to do "truly local" IP 
>breakout right at the eNB (which I imagine could also be useful in other 
>scenarios; e.g., home femtocells), but it seems inescapable to me that this 
>means implementing the SGW/PGW parts of the EPC on the eNB itself.  It can't 
>just sluff off the IP traffic locally without still pushing and popping the 
>GTP-U encapsulation on the traffic (AFAIK).

If true, this would explain why Baicells has it and Telrad doesn't: it's not 
strictly required by the standard that an eNB offer this feature (which would 
require an at least partial embedded EPC on the eNB); all that is required is 
that a PGW other than the home network one can be chosen, which was not a 
feature of GPRS or UMTS.  Perhaps once Telrad has their eEPC working on the 
Compact, this could also become a possibility on Telrad as well (instead of 
using the eEPC for *everything*, send authentication/S1-MME to a Breezeway to 
handle but have the embedded PGW terminate the user traffic).

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of Matt 
Hoppes [mattli...@rivervalleyinternet.net]
Sent: Sunday, June 19, 2016 2:20 PM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

Local offloading is a standard LTE feature. You do need an a device to do it, 
which in guessing Bai has built into their eNB.

> On Jun 19, 2016, at 17:07, Nathan Anderson <nath...@fsr.com> wrote:
>
> So it sounds like you have made Baicells eNB talk to a Breezeway for 
> authentication.  Very cool.
>
> Re: VPLS, I could be wrong (and I haven't actually tried VPLS/VPWS on 
> Telrad), but I don't believe the eNB has anything whatsoever to do with 
> making that work.  As far as it is concerned, it is just passing user 
> traffic.  In the Telrad scenario, I *think* the UE constructs a GRE tunnel to 
> the EPC.
>
> However, the fact that you say that the Baicells eNB does not send user 
> traffic to the core but only authenticates against the core might throw a 
> monkey wrench into that whole theory.  For Telrad VPLS to work, you need a 
> Telrad UE and a Telrad core, and the user traffic clearly needs to go to/from 
> the core for that to work.
>
> How does having the eNB send user traffic directly to your gateway even 
> work?? I mean, that makes sense as long as they can get away with it, because 
> I think it would be a nightmare, both from the service provider's perspective 
> as well as from Baicells' perspective, to have to carry all of the user 
> traffic to the cloud and back, but I thought LTE *required* that user traffic 
> be tunneled via GTP to the core. Does the Baicells eNB implement part of the 
> EPC (likely the SGW and PGW bits) itself?  If you wanted to, could you elect 
> to shut those off and have it ship user traffic off to an external EPC as 
> well?
>
> What do you do for SIM cards with Baicells UEs?  Does Baicells provide those 
> as well?  Have you tried a Baicells SIM in a Telrad UE and vice-versa?
>
> -- Nathan
> 
> From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
> Matthew Carpenter [mcarpen...@amarillowireless.net]
> Sent: Sunday, June 19, 2016 11:37 AM
> To: WISPA General List
> Subject: Re: [WISPA] Baicells - who's deployed it?
>
> So far I am have able to mix and match the Biacell, and Telrad eNBs and UEs.
>
> Biacell eNB connects to the core with 0 setup.
> With only one change it will connect and work with the Telrad core.
>
> UEs from both Telrad and Biacells work with either eNBs.
>
> Things to test:
> 1. VPLS from the Telrad Core to the Biacells UE using a Telrad eNB
> 2. VPLS from the Telrad  Core to the Biacells UE using a Biacells eNB (I 
> don't believe this will work. There are some updates to the Biacells eNB 
> coming out soon to add VPLS)
> 3. Does the Biacells UE support VPLS ?
> 4. Does the Biacells UE allow remote management from the Wireless side?
> 5. Do all this again with the new 19.5 dB Biscells UE.
>
> One cool thing is when the Biacells eNB is using the Telrad core it only send 
> SIM card authorization to the core.  All customer data goes out to its 
> gateway and not to the core.
>
> Matthew Carpenter
> Amarillo Wireless
> 806-316-5071
>
>
>
>
> On Sun, Jun 19, 2016 at 12:03 PM -0500, "Adair Winter" 
> <ada...@amari

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

So it sounds like you have made Baicells eNB talk to a Breezeway for 
authentication.  Very cool.

Re: VPLS, I could be wrong (and I haven't actually tried VPLS/VPWS on Telrad), 
but I don't believe the eNB has anything whatsoever to do with making that 
work.  As far as it is concerned, it is just passing user traffic.  In the 
Telrad scenario, I *think* the UE constructs a GRE tunnel to the EPC.

However, the fact that you say that the Baicells eNB does not send user traffic 
to the core but only authenticates against the core might throw a monkey wrench 
into that whole theory.  For Telrad VPLS to work, you need a Telrad UE and a 
Telrad core, and the user traffic clearly needs to go to/from the core for that 
to work.

How does having the eNB send user traffic directly to your gateway even work?? 
I mean, that makes sense as long as they can get away with it, because I think 
it would be a nightmare, both from the service provider's perspective as well 
as from Baicells' perspective, to have to carry all of the user traffic to the 
cloud and back, but I thought LTE *required* that user traffic be tunneled via 
GTP to the core. Does the Baicells eNB implement part of the EPC (likely the 
SGW and PGW bits) itself?  If you wanted to, could you elect to shut those off 
and have it ship user traffic off to an external EPC as well?

What do you do for SIM cards with Baicells UEs?  Does Baicells provide those as 
well?  Have you tried a Baicells SIM in a Telrad UE and vice-versa?

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
Matthew Carpenter [mcarpen...@amarillowireless.net]
Sent: Sunday, June 19, 2016 11:37 AM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

So far I am have able to mix and match the Biacell, and Telrad eNBs and UEs.

Biacell eNB connects to the core with 0 setup.
With only one change it will connect and work with the Telrad core.

UEs from both Telrad and Biacells work with either eNBs.

Things to test:
1. VPLS from the Telrad Core to the Biacells UE using a Telrad eNB
2. VPLS from the Telrad  Core to the Biacells UE using a Biacells eNB (I don't 
believe this will work. There are some updates to the Biacells eNB coming out 
soon to add VPLS)
3. Does the Biacells UE support VPLS ?
4. Does the Biacells UE allow remote management from the Wireless side?
5. Do all this again with the new 19.5 dB Biscells UE.

One cool thing is when the Biacells eNB is using the Telrad core it only send 
SIM card authorization to the core.  All customer data goes out to its gateway 
and not to the core.

Matthew Carpenter
Amarillo Wireless
806-316-5071




On Sun, Jun 19, 2016 at 12:03 PM -0500, "Adair Winter" 
> wrote:

You just gonna call up baicell and get the info?

On Sun, Jun 19, 2016 at 12:02 PM, Matt Hoppes 
> 
wrote:
Eh. VPN router.

On Jun 19, 2016, at 12:57, Adair Winter 
> wrote:

probably possible but since it makes some sort of ipsec connection to their 
hosted core, it would be more difficult.

The other way around works great though.

On Sun, Jun 19, 2016 at 11:53 AM, Matt Hoppes 
> 
wrote:
Since LTE is a standard  I wonder if you could hook a Telrad eNB to the 
baicells EPC??

*gear spinning*

On Jun 19, 2016, at 12:20, Adair Winter 
> wrote:

Baicells is going to have cheaper hardware but there will be some trade offs to 
other vendors.
for example, no 4x4, do dual carrier, etc.
Also you'll pay per user per month to use their core unless you already have 
one. so look at the long term when pricing.

On Sun, Jun 19, 2016 at 11:19 AM, Josh Luthman 
> wrote:

Baicells referred me to a distributor for pricing.  I asked last week.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Jun 19, 2016 12:18 PM, "Matt Hoppes" 
> 
wrote:
I've said too much. I haven't said enough.

Ask Patrick for more details on pricing.

On Jun 19, 2016, at 11:59, CBB - Jay Fuller 
> wrote:


He said "real" good ;)

- Original Message -
From: Matt Hoppes
To: WISPA General List
Sent: Saturday, June 18, 2016 7:18 AM
Subject: Re: [WISPA] Baicells - who's deployed it?

As opposed to bad? :P.

On Jun 18, 2016, at 08:03, Josh Luthman 
> wrote:


"Good"?

Josh Luthman
Office: 937-552-2340
Direct: 

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

Yeah, if you're already buying Telrad Compacts then you *probably* have a 
Telrad core, so I don't see the appeal of hooking up Telrad eNB to Baicells 
cloud core.

But the idea of hooking up a Baicells eNB to a Telrad core is interesting, 
considering the eNB price differential...use Compacts in areas where you are 
counting on the future SDR roadmap/upgradeability and the extra oomph, and 
Baicells for little micro-cell sites where you simply aren't going to have high 
subscriber density or demand and couldn't have justified a Compact to begin 
with.  Have you actually tried pointing Baicells eNB at a Breezeway?

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
Adair Winter [ada...@amarillowireless.net]
Sent: Sunday, June 19, 2016 9:57 AM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

probably possible but since it makes some sort of ipsec connection to their 
hosted core, it would be more difficult.

The other way around works great though.

On Sun, Jun 19, 2016 at 11:53 AM, Matt Hoppes 
> 
wrote:
Since LTE is a standard  I wonder if you could hook a Telrad eNB to the 
baicells EPC??

*gear spinning*

On Jun 19, 2016, at 12:20, Adair Winter 
> wrote:

Baicells is going to have cheaper hardware but there will be some trade offs to 
other vendors.
for example, no 4x4, do dual carrier, etc.
Also you'll pay per user per month to use their core unless you already have 
one. so look at the long term when pricing.

On Sun, Jun 19, 2016 at 11:19 AM, Josh Luthman 
> wrote:

Baicells referred me to a distributor for pricing.  I asked last week.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Jun 19, 2016 12:18 PM, "Matt Hoppes" 
> 
wrote:
I've said too much. I haven't said enough.

Ask Patrick for more details on pricing.

On Jun 19, 2016, at 11:59, CBB - Jay Fuller 
> wrote:


He said "real" good ;)

- Original Message -
From: Matt Hoppes
To: WISPA General List
Sent: Saturday, June 18, 2016 7:18 AM
Subject: Re: [WISPA] Baicells - who's deployed it?

As opposed to bad? :P.

On Jun 18, 2016, at 08:03, Josh Luthman 
> wrote:


"Good"?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Jun 18, 2016 8:02 AM, "Matt Hoppes" 
> 
wrote:
True. It's good though. Real good.

On Jun 18, 2016, at 02:24, Chris Ruschmann 
> wrote:


We all had to sign an NDA. So I'll let the baicells guys answer that one.

On Jun 17, 2016 9:05 PM, > 
wrote:
Whats the pricing like?

On Jun 17, 2016, at 19:12, Matt Hoppes 
> 
wrote:

https://www.facebook.com/thewirelessninja/videos/1017353051688688/

On Jun 17, 2016, at 21:07, Christian Palecek 
> wrote:

Ours*  brain fart.

We are deploying in one of our most difficult nlos areas, and another in a 
small town center so we'll have a variety of testing.



Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Christian Palecek 
>
Date: 6/17/16 7:02 PM (GMT-07:00)
To: WISPA General List >
Subject: Re: [WISPA] Baicells - who's deployed it?

We'll have ares up pretty quick, don't have a SU yet though.  Only getting one 
I guess.



Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Chris Ruschmann >
Date: 6/17/16 3:58 PM (GMT-07:00)
To: WISPA General List >
Subject: Re: [WISPA] Baicells - who's deployed it?


I should have mine deployed next week as well. Just received the gear today.

On Jun 17, 2016 1:11 PM, "Mike Francis" 
> wrote:
By: Douglas Adams
"Man [has] always assumed that he was more intelligent than dolphins because he 
had achieved so much-the wheel, New York, wars and so on-while all the dolphins 
had ever done was muck about in the water having a good time. But conversely, 
the dolphins had always believed that they were far more intelligent than 
man-for precisely the same reason."

Re: [WISPA] Baicells - who's deployed it?

[Nathan Anderson]

To the second point, Azure is supposed to be good stuff.  But to the first, if 
your users can't authenticate...

-- Nathan

From: wireless-boun...@wispa.org [wireless-boun...@wispa.org] On Behalf Of 
Adair Winter [ada...@amarillowireless.net]
Sent: Sunday, June 19, 2016 10:03 AM
To: WISPA General List
Subject: Re: [WISPA] Baicells - who's deployed it?

No, just authentication. Or at least that's the way it should be.
They are hosting in azure and are supposed to have some good redundancy .

On Sun, Jun 19, 2016 at 12:01 PM, 
> wrote:
So if their hosted core takes a sh*t, all your users are down?

On Jun 19, 2016, at 09:57, Adair Winter 
> wrote:

probably possible but since it makes some sort of ipsec connection to their 
hosted core, it would be more difficult.

The other way around works great though.

On Sun, Jun 19, 2016 at 11:53 AM, Matt Hoppes 
> 
wrote:
Since LTE is a standard  I wonder if you could hook a Telrad eNB to the 
baicells EPC??

*gear spinning*

On Jun 19, 2016, at 12:20, Adair Winter 
> wrote:

Baicells is going to have cheaper hardware but there will be some trade offs to 
other vendors.
for example, no 4x4, do dual carrier, etc.
Also you'll pay per user per month to use their core unless you already have 
one. so look at the long term when pricing.

On Sun, Jun 19, 2016 at 11:19 AM, Josh Luthman 
> wrote:

Baicells referred me to a distributor for pricing.  I asked last week.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Jun 19, 2016 12:18 PM, "Matt Hoppes" 
> 
wrote:
I've said too much. I haven't said enough.

Ask Patrick for more details on pricing.

On Jun 19, 2016, at 11:59, CBB - Jay Fuller 
> wrote:


He said "real" good ;)

- Original Message -
From: Matt Hoppes
To: WISPA General List
Sent: Saturday, June 18, 2016 7:18 AM
Subject: Re: [WISPA] Baicells - who's deployed it?

As opposed to bad? :P.

On Jun 18, 2016, at 08:03, Josh Luthman 
> wrote:


"Good"?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Jun 18, 2016 8:02 AM, "Matt Hoppes" 
> 
wrote:
True. It's good though. Real good.

On Jun 18, 2016, at 02:24, Chris Ruschmann 
> wrote:


We all had to sign an NDA. So I'll let the baicells guys answer that one.

On Jun 17, 2016 9:05 PM, > 
wrote:
Whats the pricing like?

On Jun 17, 2016, at 19:12, Matt Hoppes 
> 
wrote:

https://www.facebook.com/thewirelessninja/videos/1017353051688688/

On Jun 17, 2016, at 21:07, Christian Palecek 
> wrote:

Ours*  brain fart.

We are deploying in one of our most difficult nlos areas, and another in a 
small town center so we'll have a variety of testing.



Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Christian Palecek 
>
Date: 6/17/16 7:02 PM (GMT-07:00)
To: WISPA General List >
Subject: Re: [WISPA] Baicells - who's deployed it?

We'll have ares up pretty quick, don't have a SU yet though.  Only getting one 
I guess.



Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Chris Ruschmann >
Date: 6/17/16 3:58 PM (GMT-07:00)
To: WISPA General List >
Subject: Re: [WISPA] Baicells - who's deployed it?


I should have mine deployed next week as well. Just received the gear today.

On Jun 17, 2016 1:11 PM, "Mike Francis" 
> wrote:
By: Douglas Adams
"Man [has] always assumed that he was more intelligent than dolphins because he 
had achieved so much-the wheel, New York, wars and so on-while all the dolphins 
had ever done was muck about in the water having a good time. But conversely, 
the dolphins had always believed that they were far more intelligent than 
man-for precisely the same reason."

John Michael Francis II
JMF Solutions, Inc
Wavefly Technologies
Internet - Voip - Cloud

Re: [WISPA] Look up DID owner

[Nathan Anderson]

Have you tried an LRN lookup?

Feel free to hit me up off-list with the number in question.

-- Nathan

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Chris Fabien
Sent: Monday, June 13, 2016 2:26 PM
To: WISPA General List
Subject: [WISPA] Look up DID owner


We are having a porting problem. Is there anyone who can lookup a number and 
find out whose system we are hitting when we dial it. It's a current customers 
porting away from us and I think the other provider messed up the port but are 
blaming us.
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Small IP PBX - Grandstream UCM

[Nathan Anderson]

Yeah, I've thought about trying a Raspberry Pi as a cheap, IP-only PBX.  Should 
have more than enough oomph for a small office environment.

We have had great success running Asterisk directly on MikroTik RouterBoards, 
inside of a MetaROUTER VM.  Of course, both this solution and the Raspberry Pi 
can only be used in a pure IP environment.

Those Blackfin-based embedded Asterisk systems that Atcom et al. manufacture 
(http://www.rowetel.com/blog/?page_id=440) are also intriguing, but I haven't 
been able to find a good U.S.-based supplier/distributor.

-- Nathan 

-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Scott Carullo
Sent: Thursday, May 15, 2014 6:53 AM
To: Bryce Duchcherer; sc...@brevardwireless.com; WISPA General List
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM

Oh yeah - I should have noted - we have one running at customer site for 16 
phones and its a blueberry pie or whatever those things are called lol.  Cost 
less than 100 bucks and we even have two network interfaces on them (one usb)
 
Scott Carullo
Technical Operations
855-FLSPEED x102

 http://www.flhsi.com/files/emaillogo.jpg 
 


From: Bryce Duchcherer bduc...@netago.ca
Sent: Wednesday, May 14, 2014 6:16 PM
To: sc...@brevardwireless.com sc...@brevardwireless.com, WISPA General 
List wireless@wispa.org
Subject: RE: [WISPA] Small IP PBX - Grandstream UCM 
 

I have one of these coming in to try out, they're dirt cheap and are supposed 
to be decent. They support up to 8 calls and are supposed to run on asterisk.

http://www.atcom.cn/IP02.html

 

 

Bryce D

NETAGO

 

From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Scott Carullo
Sent: Wednesday, May 14, 2014 16:08
To: WISPA General List; WISPA General List
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM

 

I've never been a fan of anything grandstream has ever made so I wouldn't go 
there.  JMO

 

Get some other solution for the PBX (running your own software on a nice little 
atom works great / some flavor of asterisk) and do yourself a favor and pick up 
some yealink phones.  The name kept me away from the longest time but I have 
tried dozens of phones and right now a T46G is on my desk and I won't give it 
up.  Great price too.  Best phone I have ever used and previously I had polycom 
soundpoint 650.  This one hands down is a better solution and its half the 
price.

 

Sh...  don't tell everyone I need them in stock!

 

Scott Carullo
Technical Operations
855-FLSPEED x102

 http://www.flhsi.com/files/emaillogo.jpg 

 



From: Chris Fabien ch...@lakenetmi.com
Sent: Wednesday, May 14, 2014 1:29 PM
To: WISPA General List wireless@wispa.org
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM 

 

It seems like a box on site would make routing/nat issues easier to manage 
especially for customers who may not have our Internet or want to keep a second 
internet provider for redundancy.  It seems like a bunch of ip phones behind 
nat connecting up to our switch or a hosted solution would be problematic.

  If you have a suggestion on a solid solution i'm all ears, want to learn 
whats available and how others are doing this.

On May 14, 2014 1:21 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 

Why do you want to put  a 'box' on-site ?

 

Why not hosted PBX, and have IP Phones  ?

 

Regards.

 

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232 tel:305%20663%205518%20x%20232  

 

Help-desk: (305)663-5518 tel:%28305%29663-5518  Option 2 or Email: 
supp...@snappytelecom.net

 



From: Chris Fabien ch...@lakenetmi.com
To: WISPA General List wireless@wispa.org
Sent: Tuesday, May 13, 2014 11:40:10 PM
Subject: [WISPA] Small IP PBX - Grandstream UCM 

 

Anyone tried out this Grandstream IP PBX? Looking for a low 
cost option we can use for small businesses with 4-8 phones. Also need to redo 
our office phones so I have a nice chance to try out a new product before 
selling one to a customer. Any suggestions other than the grandstream are 
welcome too.


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

 


___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
 

___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Small IP PBX - Grandstream UCM

[Nathan Anderson]

On Thursday, May 15, 2014 11:49 AM, Faisal Imtiaz  wrote:

 First of all, thank you for this great discussion, while we are
 discussing the finer points of how we approach things, I would like to
 state for the record, it is not my intent to critique one method over the
 other, rather a discussion on how we solve the common issues related to
 providing the service to our customers.
 
 It is also refreshing to get some overview details on how each of our
 inhouse systems are created / configured / integrated. Speaking for
 myself, I always get some good ideas / feedback from such discussions,
 and hopeful provide the same for yourself and or others.   

Agreed on both counts!

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Small IP PBX - Grandstream UCM

[Nathan Anderson]

Working around NAT issues with SIP and RTP has little-to-nothing to do with 
whether the PBX lives in the cloud or is a local piece of hardware.  We do 
not (at this time) do hosted PBX ourselves, and NAT is generally not a problem.

Our strategy isn't even to use something like STUN or TURN.  It is simply to 
employ a B2BUA architecture, where both the SIP and RTP traffic is always 
guaranteed to come from a single IP, the same one that the customer phone or 
PBX initiated communication with when it registered itself to our SIP+RTP proxy 
(and we require SIP registration and don't offer static IP authentication as an 
option).  We also use a low SIP registration expiration timer.  That way the 
necessary port mappings are already in the NAT router's connection tracking 
table, so when an unsolicited SIP message hits their router, it gets sent to 
the right place, and those entries in the table are constantly getting 
refreshed.

It probably doesn't hurt that in many cases, we also end up selling the 
customer a router that actually has a decent SIP ALG implementation 
(MikroTik/Linux).  But I've found that even with the ALG turned off, everything 
still works fine.

Security of a local PBX is also relatively straightforward.  DO put the PBX 
behind a NAT, and DON'T create any static port forwards to it on the NAT 
router.  Just let NAT/conntrack and the ALG do their jobs.  Then unsolicited 
SIP traffic coming from hosts other than your own SIP proxy will never reach 
their PBX.  Any attacker would first have to compromise the NAT router, and if 
they didn't have any reason to believe that you were running an IP PBX behind 
it anyway (and why would they if external scans never generated a response to a 
SIP message?), they would have no reason to go to the trouble of attempting to 
break into the router in order to gain access to the PBX, unless they were 
targeting your organization specifically (so, a person who had a beef with 
you/your customer, and not some automated bot spewing SIP INVITEs to thousands 
of public IPs).

I am personally not a fan of the whole hosted PBX craze myself, although we may 
eventually feel the pressure of coming out with a product like that for our 
customers if the demand becomes such that we can no longer ignore it.  I don't 
really get why people want it or where the benefit is.  I think most people 
just have it in their heads that if they pay per port for a hosted solution, 
that method of pricing service has some inherent cost-savings built into it.  
That, and they think that having the PBX in the cloud rather than local means 
that it's one less piece of gear for them to maintain.  But there is nothing 
preventing somebody (like the provider) from selling or renting the end-user a 
piece of hardware and also maintaining it for them remotely.  The end result is 
the same: the customer doesn't have to worry about it.  The huge downside I see 
with hosted PBX is that if the internet connection goes down or the cloud PBX 
becomes unreachable for some other reason, then all the 
 phones that happen to be in the same building and connected to the same LAN 
don't work at all, even for, say, local phone-to-phone intercom calling in the 
same building, or group paging, or what-have-you.  If you tried to sell a 
business individual internet connections for each computer in their 
organization, where all of the computers would have to go through the internet 
in order to exchange data with each other, people would think you are nuts.  So 
why are people so eager to sell (and buy) phone service that works on the same 
principle?

But I digress.

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com

-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Faisal Imtiaz
Sent: Wednesday, May 14, 2014 4:32 PM
To: WISPA General List
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM

We find it easier to manage nat/routing issues via a hosted pbx.
   (Pbx is hosted on a Virtual Server VPS at the DataCenter)
 Using Mikrotik's as client routers  (managed router service) is very practical.
 
Setting up Dual ISP with Failover is a bit daunting task, however if you 
follow this, recipe to get it done..
  http://mum.mikrotik.com/presentations/US12/tomas.pdf

Plus it is my opinion, that it is easier to manage / monitor / secure the PBX 
at the datacenter than one at client site.

Regards.

Faisal Imtiaz
Snappy Internet  Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232


Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net 





From: Chris Fabien ch...@lakenetmi.com
To: WISPA General List wireless@wispa.org
Sent: Wednesday, May 14, 2014 1:29:14 PM
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM



It seems like a box on site would make routing/nat issues easier to 
manage especially for customers who may

Re: [WISPA] Small IP PBX - Grandstream UCM

[Nathan Anderson]

 which one is more inherently secure.  (Of 
course, just beca
 use it is behind a NAT does not mean you can eliminiate active vigilance and 
policing of the PBX itself, or that you don't need to enforce any additional 
security policies.)

There is also absolutely nothing that prevents us from setting up call 
forwarding to cell phones or from having a backup voicemail box take calls in 
the event that our communication with the end-user's PBX is interrupted.  Our 
home-grown platform absolutely allows us to do this, and I'm sure it is not 
unique in this regard.

I agree that ultimately what this comes down to is a business philosophy, but 
business philosophies can have either a positive or negative impact on the end 
product and the customer experience.  I hear you on trying to avoid truck-rolls 
to customers, but for the majority of the stuff that you might be asked to do 
for a customer's PBX if it was on-site, you could do all of those things 
remotely, just the same as if the PBX was some VM that existed on some public 
server out there.  For example, if a remote client wanted us to turn up a new 
extension for them with a new local DID, I could do all of that from the 
comfort of my desk without dispatching anyone, just the same as you.  The only 
thing I can think of that would be an exception to that is hardware failure, 
which is a real possibility.  So what I am hearing is that hosted PBX has all 
of these supposed benefits, but all of those benefits are ones that favor the 
provider of the service by making things more convenient for them, an
 d which doesn't necessarily provide additional value-add for the end-user (and 
in fact might take away some value, depending on how you look at it).

I also agree about looking at it from a service provider perspective, but I 
guess I disagree with what that actually looks like.  Like you, I am not 
interested in making money by selling hardware.  I want to sell service.  To 
me, what that means is selling either a single line of service (e.g., residence 
using an ATA) or a SIP trunk that peers with a PBX of that user's choice.  In 
either case, what I care about are the recurring monthlies.  If the customer 
doesn't have an ATA or PBX that they are bringing to the table, then we can 
sell them one and even set it up for them and configure it such that we can get 
into it remotely to actively manage it for them.  This is the *exact same 
philosophy* that we follow when it comes to internet connectivity: if the 
customer has a router that they want to use, fine.  If they don't, we'll sell 
them one.  If they want us to help with its configuration (either one-time or 
on an ongoing basis), we can do that, too.  But all of that is just to keep t
 he monthly service revenues coming in.  We are simply trying to be consistent 
in the way that we approach both data and voice services.  Treating IP routing 
one way (local router + LAN) and PSTN routing another (everything is hosted/in 
the cloud) just doesn't make sense to me.

Again, thanks for the discussion!

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com

-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Faisal Imtiaz
Sent: Wednesday, May 14, 2014 8:54 PM
To: WISPA General List
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM

Agreed, that SIP/RTP   NAT issues are non-issue when you are using a consistent 
Router such as Mikrotik.

B2BUA (Back to Back user agent, e.g. asterisk to asterisk) has its advantage 
and also it's own set of issues (typically in Codec Conversion ...

STUN or TURN are not necessary either, all depends on the deployment.

We don't depoly sip proxy either, we spin small instances (openvz) for each 
customer, have a scripted install for Freepbx, security etc.. let the phones 
register to the pbx directly.

I strongly disagree about security for the pbx, it is irrelevant if the pbx is 
hosted or on client premises, security has to be proactive and reactive, static 
security is not sufficient, I believe it is less work maintaining a number of  
VPS vs a number of distributed hardware devices located at multiple client 
premises.

As to the question of Hosted vs On-Premise, the right answer has to do with 
what I call external factors...
e.g. in our neck of the woods, travel time is a significant factor, and cost of 
professional labor is high...
being able to manage VPS, provisioning, backup, etc etc (we do all of this 
remotely from our office on machines located at the Data Center), we are able 
to do things much more efficiently than dealing with travel time and running 
around town. (Heck, only today,  I turned up two new extension, one in 
Oklahoma, and another in Tennessee, for a Client based out of Carmel,IN, with 
local DID's, and these two extension are ready to be in service for tomorrow's 
business day !)

I will agree with you that, having an on-premise pbx is advantageous when there 
is an internet outage

Re: [WISPA] Small IP PBX - Grandstream UCM

[Nathan Anderson]

After re-reading what I wrote, I guess I should clarify the following:

We have a homegrown SIP-based telephony service that is built on top of 
Asterisk, but which is emphatically not hosted PBX.  We can provision an 
account as either a single line (one DID, one SIP registration from an ATA, 2 
channels for call-waiting) or a SIP trunk (multiple DIDs, one SIP registration 
from a PBX, multiple channels), and whether it is a single-line or trunk 
account, the customer has the option of specifying an emergency call forward 
number that calls are sent to if either their ATA or PBX goes down for whatever 
reason, or if our main NOC goes down completely (worse-case scenario where all 
connectivity and power redundancy utterly fails).

So we are using Asterisk, but we are not using it on our side in our NOC as a 
PBX in the traditional sense or understanding.  We are using it more like a 
telephony software platform or SDK.  If a customer needs a PBX and doesn't have 
a preference, we will sell them an Asterisk-based one (an Asterisk instance 
that is configured more traditionally) to live on their premesis, and typically 
also set up VPN access to it so that we can manage and troubleshoot it 
remotely.  That on-site PBX will get calls sent to it from our Asterisk-based 
server.

We do have enterprise-ish customers that do want BYOPBX, and they successfully 
peer (via SIP) with our Asterisk server using things like (e.g.) Cisco 
CallManager/UCM.  So I feel that by attacking the voice provisioning problem in 
the same way that we attack data provisioning, we give customers options and 
flexibility that allow us to serve customers we would otherwise have to turn 
away, or who wouldn't even give us a passing glance.

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com

-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf 
Of Nathan Anderson
Sent: Wednesday, May 14, 2014 10:17 PM
To: 'WISPA General List'
Subject: Re: [WISPA] Small IP PBX - Grandstream UCM

Lots to address here. :)  Thanks for engaging.

By B2BUA, I don't mean Asterisk to Asterisk.  I mean something like Asterisk 
itself...Asterisk is, by its very nature, a self-contained back-to-back user 
agent.  That is, it doesn't just forward SIP messages from a proxy or UA 
upstream.  It pretends to be both the final endpoint as well as the original 
calling UA, inserting itself into the middle of the conversation at all levels: 
it answers the incoming INVITE itself, and then generates a brand-new INVITE 
with a different ID/sequence number that it sends on, as if the originating 
INVITE is coming directly from that Asterisk instance.  Asterisk also can proxy 
the RTP audio as well, such that the SDP content in the INVITE points back at 
itself rather than whatever the originating media gateway is.

In a typical SIP switching/proxy architecture, this is just not done...the host 
that the target UA gets its marching orders from (SIP INVITE, etc.) is not 
necessarily where the audio stream comes from.  It's also not necessarily the 
same proxy that future SIP messages for that particular session are expected to 
come from or go to.  The RTP media gateway is oftentimes at a completely 
different IP address.  All of this can serve to make the whole scheme very 
NAT-unfriendly and also makes crafting competent ALGs more tricky than one 
might assume.  So NAT issues can arise even with known-good routers, and my 
point was not really that we are solving the problem by using good routers, 
but that we are trying to eliminate the problem at a different level so that we 
don't have to care 99% of the time what router a customer is using.  Reducing 
the multitude of IP addresses that are involved in a typical SIP session from 
the destination UA's perspective down to a single IP plays a huge part i
 n this.

Asterisk is a B2BUA in the SIP context not because that's what the authors of 
Asterisk consciously intended when it came to adding SIP support, but is rather 
that way by its very nature, because it was written from the ground up to be a 
technology-agnostic telephone platform, not a SIP-specific platform.  Asterisk 
needs to be able to bridge channels from disparate interfaces and technologoes 
(TDM to SIP, analog to TDM, etc.).  Asterisk treats SIP-to-SIP calls no 
differently internally than it treats SIP-to-ISDN or analog-to-PRI.  The 
Asterisk core actually has no clue what technologies are behind the two channel 
legs that it is being asked to bridge together...that all gets abstracted away 
by the channel drivers.  And at its core, Asterisk already knows how to do 
audio transcoding because it needs to be able to do that in order to fulfill 
its stated mission, even if it didn't have SIP support at all.  In actuality, 
if all you are dealing with is pure SIP, a B2BUA such as Asterisk i
 s technically not as efficient from a resources perspective...because it is 
having to keep track of state

Re: [WISPA] OT Fax over Voip

[Nathan Anderson]

On Wednesday, April 02, 2014 6:04 AM, wi...@mncomm.com  wrote:

 Regardless I cannot get these to work 10 feet to each other over cable.
 Voice works great.

Again, *what* doesn't work?  You haven't described the symptoms of not 
working to us at all.  We can only make assumptions without exact details of 
the problem.  How far does it get?  Are you losing pages?  Parts of pages?  
Does it not even begin the transmission?  Do you have the speaker enabled on 
the fax machine and can you hear the attempted handshake with the other side?  
Do you note any differences in how it sounds going between the VoIP gateways 
and when it is plugged straight into an FXS provided to you directly from the 
CO?  What error message does the fax machine spit out at you, if it does in 
fact spit one out?

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] OT Fax over Voip

[Nathan Anderson]

On Wednesday, April 02, 2014 6:55 AM, Fred Goldstein  wrote:

 But in addition to that, I STRONGLY recommend a separate VLAN for the
 voice-grade channels.  With priority, or reserved bandwidth. TCP/IP in
 normal operation manages its flow rate by having packets thrown away;
 that's why the 1G LAN port on your PC doesn't blast a whole file at 1G
 into a 2M link.  It uses packet loss as a signal. TCP applications
 retransmit and actual human voice is intelligible with some gaps, but
 modems, including fax, are very unhappy.

Do note that RTP is implemented over UDP, not TCP, so in VoIP, a dropped audio 
packet is a lost audio packet, not a delayed or even out-of-order audio packet 
(although those other two things can happen...they just aren't a result of 
retransmits, or at least not a retransmit initiated by Layer 4).

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] OT Fax over Voip

[Nathan Anderson]

On Monday, March 31, 2014 8:51 AM, l...@mwtcorp.net  wrote:

 I don't want to start a long thread about fax but --RANT

[...snip excellent fax rant...]

+1

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] OT Fax over Voip

[Nathan Anderson]

On Monday, March 31, 2014 7:04 AM, wi...@mncomm.com  wrote:

 So, the scenario would be the CO goes into a gateway device to convert to
 digital, goes over the LAN to the other gateway device. That device hooks
 up to the fax machine. If someone has done this before can you share the
 products you may have used? The products we have say they will work this
 way, but no luck, just voice transmission. I may have a bad device as
 well. 

If you are talking about a private point-to-point wireless link shot between 
two buildings across a parking lot or whatever, with excellent link quality 
characteristics and low jitter and latency, there is no reason that I can think 
of why moving the fax machine over wouldn't just work.  Perhaps you could 
share with us the following:

1. Model of the Grandstream gateways in question.
2. How you have the gateways configured (e.g., codec being used and such).
3. What equipment you are using to do the wireless shot.
4. Average throughput, latency, and jitter across that link.
5. Whether the link is for phone use only, or is combined voice and data.
6. ...if combined, whether any kind of QoS is being employed to promote voice 
transmission ahead of data.

...and, most importantly...

7. What exactly happens when you try to send or receive a fax over the gateway 
devices.

A vague it doesn't work description never helped anybody solve anything. :-)  
Give us details.  How does it fail, exactly?  How far along does it get?  Is it 
able to transmit a partial page and then the connection drops?  Or can it not 
even complete the handshake with the other fax machine?  If it works for voice, 
I very much doubt you have a bad device, unless it is a software/firmware 
issue on the device(s).  If the device was physically bad, I suspect the defect 
would present itself in other ways as well.

General things to try out and to look out for:

If you are using some fancy, efficient voice codec like G.729, turn that crap 
off.  Limit both gateways to negotiate G.711u with each other only.

If they have a T.38 option, make sure it is either enabled on both sides, or 
disabled on both sides...if there is a mismatch, some SIP stacks behave very 
badly if/when their re-INVITE to T.38 is rejected by the other peer.

If the gateway devices support T.38 and it happens to be enabled, try turning 
it off.  The T.38 spec is so vague as to often be useless, and there can be 
interop problems even between two identical devices (I swear that sometimes 
vendors don't test their own products...it's infuriating).  And on a private, 
short-haul link like that, I would sure think that using G.711u PCM for both 
voice and fax transmission would be sufficient and pose no problems.

On the other hand, if latency and jitter are sometimes a problem and the 
quality of the link is in doubt, and you haven't been using T.38, then by all 
means give T.38 a try, assuming your Grandstream devices can act as T.38 
gateways (it's not enough for them to have T.38 passthrough support, they must 
have GATEWAY functionality).  Once you finally get past all of the interop 
issues, T.38 really can work magic for FoIP on uncontrolled IP links.

If you are using T.38 (or, heck, even if you aren't using T.38), try forcibly 
lowering the maximum modulation rate that their fax machine will attempt to 
handshake to the other side with.  It is still (sadly) incredibly common for 
most production T.38 implementations these days to be based off of version 0, 
which does not include support for gatewaying V.34, only V.17.  If they have a 
Super G3 fax machine, the T.38 gateway feature should in theory just ignore 
the handshake and not even engage and try to re-INVITE to T.38, but you never 
know...could be buggy.  Or if you aren't using T.38, V.34 modulation rates 
could be more sensitive to timing and jitter issues.  So limit the fax machine 
to 14400bps or 9600bps.

Hope this helps,

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless