Yes, good point (same point was made by Geoff). It means using a special
voice subdomain, but it does make life easier.
I prefer to use the main company domain because [email protected] looks
better than [email protected]
but normally you don't use the domain name anyhow because most people
stick to numbers
or contact lists or directory searches.
Paul
"McIlvin, Don" <[email protected]> wrote on 25-05-2012
17:51:28:
> So comments marked DM>> where 3 options are discussed.
> From: [email protected] [mailto:sipx-users-
> [email protected]] On Behalf Of [email protected]
> Sent: Friday, May 25, 2012 7:24 AM
> To: Discussion list for users of sipXecs software
> Subject: Re: [sipx-users] Unmanaged services plan for 4.6
>
> Douglas Hubler <[email protected]> wrote on 25-05-2012 11:01:14:
>
> > On Fri, May 25, 2012 at 2:59 AM, <[email protected]> wrote:
> > >> then we should make sure webmin works. Did you typically install
> > >> webmin on sipxecs systems before or just thinking ahead?
> > >
> > > I think it is important that there is at least also a UC interface
where
> > > the important things for the UC system can be set. Like certain DHCP
> > > options.
> >
> > yes, agree.
> >
> > >> The DNS doesn't have to be the same that your entire company uses.
I
> > >> cannot find a good reason not to run the DNS.
> > >
> > > IP address management is a reason why the "company DNS" should at
least
> > > reflect
> > > the A records of IP addresses that are used.
> >
> > yes, a common setup is to copy records (A or SRV) records from the
> > sipxecs system for SIP and IM to your company DNS server. sipxecs
> > maintains it's own DNS because "everything is a DNS issue" and sipxecs
> > breaks horribly all the time when we rely on company DNS server to be
> > correct. In addition the number of records we require now for a HA
> > system has exploded because a lot more services are HA now. If before
> > copying the "RR" records was problematic, now it's 10x worse. The
> > silly thing is that these records were only used internally by sipxecs
> > so why make admins go thru the torture. Funny thing is this hasn't
> > changed much from 4.4, but it wasn't clear before that this is
> > actually what happened.
>
> So we have 2 usertypes:
> - the UC client devices, these are mainly hardphones and softphones on
any OS.
> These need access to the SIP SRV records etc.
> Since the world is moving more and more to software I think in
> bigger installations
> these should run from the "company DNS".
> - the UC servers, these need a separate set of DNS records, only
> used between them.
> These can be provided by the "UC DNS".
>
> There are then 3 options:
>
> DM>> There may be a 2b)
>
> 1) Use UC DNS for servers and UC clients, this would mean that the
> UC clients only need the standard
> UC records or there is a forwarding to the company DNS. There also
> has to be a (DHCP) way to point the UC
> clients to the UC DNS instead of the company DNS if it's not the same.
> 2) Use UC DNS for the servers and the company DNS for the clients,
> this means putting the
> necessary records in the company DNS. All records are available on
> the UC servers as well.
> This is the safest I think because the client records are available
> everywhere. No changes on DHCP.
> DM>> 2b)Where Clients use company DNS servers to request resolution
> of the SIP Domain name, but company DNS servers only forward
> resolution of SIP to UC Servers.
> DM>> No actual records per se in company DNS.
> DM>> Administration of Bind capabilities like Views to manage
> traffic flow on a large network, and load balancing is contained
> within UC servers.
> DM>> All named references to gateways are self contained within UC
> servers as well.
> DM>> Also ensures a regional proxy server can be set to use its own
> local resources and not that of another regional proxy
> (topologically far way).
>
> 3) Use company DNS for all, meaning entering all records in the company
DNS.
> This requires special skills and time, but would work OK.
>
> Do you want all 3 options?
> 1) Is a good option if the UC DNS&DHCP is the main DNS/DHCP, webmin
> would be nice then as well.
> If there is another company DNS&DHCP then 2) can be used (if wanted
> in combination with 1))
> I am now using option 3), this would be more for the bigger
> organisations were everything has
> to be controlled centrally. In the future I might swap to 2) to make
> sure the server part is OK.
> 1) is not an option because we have a high available fully managed
> IP address management solution
> in place for all clients (UC or not UC).
>
> > _______________________________________________
> > sipx-users mailing list
> > [email protected]
> > List Archive: http://list.sipfoundry.org/archive/sipx-users/
> "The information in this electronic mail message is the sender's
> confidential business and may be legally privileged. It is intended
> solely for the addressee(s). Access to this internet electronic mail
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying, distribution or any action taken
> or omitted to be taken in reliance on it is prohibited and may be
unlawful."
> "The sender believes that this E-mail and any attachments were free
> of any virus, worm, Trojan horse, and/or malicious code when sent.
> This message and its attachments could have been infected during
> transmission. By reading the message and opening any attachments,
> the recipient accepts full responsibility for taking protective and
> remedial action about viruses and other defects. The sender's
> employer is not liable for any loss or damage arising in any way
> from this message or its attachments."
> "In connection with representing sellers and/or buyers in real
> estate transactions, Coldwell Banker Residential Brokerage real
> estate sales associates have absolutely no authority to create
> binding contractual obligations on behalf of a seller or on behalf
> of a buyer via any written or verbal communications including, but
> not limited to email communications." [v1.0.07.109]
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
