MRA (Mobile and Remote Access) is a technology that allows phone registrations without raw sip signaling sent over the internet. I compare it to RPC over HTTPS proxy, aka “Outlook Anywhere.” Email came first, now I’m not sure if anyone remembers having to VPN in for Outlook to work.
After having several MRA projects back to back, I’ve found that most of the lessons I’ve learned were dealing with project management than the technical pieces. No other piece of hardware or software requires so many different groups of people: the datacenter guy, the firewall guy, the certificate guy, the dns guy, the voice guy. Throw in a business analyst and a project manager and it gets messy. I literally had projects ongoing for months and months when I was able to get MRA working in my lab in just a couple hours. Anytime I finish a project I look at how it could’ve been done better, so here it is:
First: It’s better to think of MRA as 5 separate, independent tasks because almost nothing depends on anything else.
- VM Deployment
- Networking
- Certificates
- DNS
- Firewall
Second: Clearly define roles and responsibilities per task at the onset of the project. The certificate guy doesn’t care about ip addresses or storage so just gather contact information and give role takers hyper-specific information to keep their attention. Limit emails.
Third: Make the configuration as cookie-cutter as possible. I wouldn’t even mention single NIC with some nat reflexion workaround, you use the advanced networking key with an outside and an inside interface. Public Certs on everything. It’s always a cluster, even if its a cluster of one; you never know when they will scale up. I assume inside out, everything is allowed through the firewall; this is usually the case and customers get confused with the lengthy cisco documentation. I usually give something like below:
|
Purpose |
Protocol |
Internet Endpoint (source) |
Expressway-E (listening) |
|
XMPP |
TCP |
>=1024 |
5222 |
|
XMPP federation |
TCP |
>=1024 |
5269 |
|
HTTP proxy (UDS) |
TCP |
>=1024 |
8443 |
|
SIP media |
UDP |
>=1024 |
36002 to 59999 |
|
SIP signaling |
TLS |
>=1024 |
5061 |
|
HTTPS (Unity) |
TCP |
>=1024 |
443 |
Also, I posted before about Flexible Jabber ID, which allows for multiple presence domains. That can cause holdups if you aren’t allowed to sign for these domains for your cup-xmpp certificate. It becomes an all-or-nothing service model. The best thing to do is get ahead of this and remove services from domains that you cannot sign for! You can run a whois lookup to ensure the technical contact has some relationship with the customer.