> DNS SRV on the public side can be used if you want to let phones register
> without using the static ip in the outbound proxy but its not required.  
> Handy if users want to transport phones offsite without making any changes.

I had so many combinations of setup before it all started working right that 
it's gotten confusing. At the time, I was going to use OpenSBC with a couple of 
WAN connections. Had problems, eventually went with pfsense for the SIP/RTP 
connections to sipx. At the time, I was doing a load balanced setup so things 
looked like;

_sip._tcp.mydomain.com.        IN SRV 1 1 5060 pf5.mydomain.com.
_sip._udp.mydomain.com.        IN SRV 1 1 5060 pf5.mydomain.com.
_sip._tcp.mydomain.com.        IN SRV 1 1 5060 pf6.mydomain.com.
_sip._udp.mydomain.com.        IN SRV 1 1 5060 pf6.mydomain.com.

When I went to pfsense, I just changed things to;
_sip._tcp.mydomain.com.        IN SRV 1 1 5060 pf6.mydomain.com.
_sip._udp.mydomain.com.        IN SRV 1 1 5060 pf6.mydomain.com.

and removed the other records.

>Remote users do not use the DNS SRV records.  For a remote user you have to 
>change the outbound proxy to an
>IP address (not a domain name). 
>Once this is done, the phone sends its registration and calls to this external 
>IP (which is sipx remote NAT feature)....
>it in turn does all the magic for you. DNS SRV on the public side can be used 
>if you want to let phones register
>without using the static ip in the outbound  proxy but its not required.  
>Handy if users want to transport phones
>offsite without making any changes.

Whew, that throws everything I thought I understood about needing SRV records 
right out the window.
I can't even recall how far back I thought everything had to be SRV based, 
including remote phones in order for everything to work. I'm not sure where 
things went sideways for me but I know I need to understand this. Problem is, 
I've got a few servers in production and want to make sure that everything is 
as clean as possible, including dns records. Very nervous about making changes 
that might take anything down.




_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to