>>> On 4/2/2009 at 1:39 PM, in message <[email protected]>, "Dale Worley" <[email protected]> wrote: > On Thu, 2009-04-02 at 13:03 -0500, Tony Graziano wrote: > > I'm trying to understand the current method used to send a register > > request. > > > > What I think i'd like to see long term is a 2nd ip address bound > > simply to the remote register function, and see the register requests > > forward to that (private) ip and allow the traffic between trunking > > and remote users become better segregated at some point in the future. > > I would think that the second address scheme would also lend itself to > > being able to blend it into HA more easily. > > > > Does this make sense to anyone else? > > The method used to send a register request is rather tightly specified. > Also, remember that it is done by the *phone*, under direction of the > DNS records that it can see, so we Gods of sipX (TM) don't have that > much control over the process. > > The REGISTER request must be constructed with the request-URI of > "sip:<whatever your SIP domain is>". That domain will be looked up for > SRV, CNAME, and A records (and possibly NAPTR records). The result will > be a list of IP addresses (and ports), ordered by priority and between > addresses of the same priority, a "weight" telling what fraction of the > traffic is to be sent to each one. Those IP addresses/ports are where > the phone sends the REGISTER request. This is specified in complete > detail in RFC 3263. > > (Many phones allow specifying an alternative URI as the "outbound > proxy", in which case the outbound proxy URI is looked up, rather than > the SIP domain.) > > What is it you're trying to accomplish? What is the overall system > configuration you are contemplating? > > Dale > > >
I'm constructing a document to show the basic items needed to use ITSP trunking and remote workers natively in 3.11.x, and also a basic how-to guide to get things started. One of the first things I found out was that remote users would have to reconfigure when they are "on" the local network (vpn or otherwise) as opposed to using sipxbridge/sipxrelay unless sipx had been manually configured to run on a different port, and then the DNS records become somewhat "different" in reality as opposed to anything already published. In my case my workaround for that was OK, because my ITSp allows me to re-configure what port they send to me on, so the remote worker doesn't change. At the same time, I started looked at how I am doing things today, which works well. In my case I have a sip aware appliance doing trunking and remote worker connections, and sipx uses it. One of the things I also saw is how the appliance is using two internal IP's addresses, one dedicated for remote workers, that lets me see the registration in sipx pointed to this secondary address, because it forwards those to sipx and "relays" it, keeping trunking traffic separate from registration and user messages. I thought a little further and wondered what "if" this secondary IP was used in a simlar fashion in sipx, and how it could lend itself to behavior that makes it possible to let users failover (DNS I think would do this) in a remote fashion. As I recall some providers won't give you the flexibility of specifying ports, so this could be a more long-term, permanent solution to keeping everything "standard' in your port and DNS assignments. Then I thought i need to re-start my 3.11 system here and try a few things, so I am doing that now. I think it would be good if the admin type could look and see the user was registered remotely because they are using a dedicated IP on the network used for registrations only. So I am just contemplating whether or not my though process is valid from a model perspective and whether or not I accurately understand the system as it is being developed. Tony _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
