On Thu, Oct 9, 2008 at 3:39 PM, Dale Worley <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-10-09 at 12:01 -0400, M. Ranganathan wrote:
>> Problem:
>> Currently there are no checks on port allocation and there is no
>> allocation service that works across all the different services that
>> need to use ports on a given sipx. It is easily possible to allocate
>> conflicting port ranges in generating configuration files.
>
> And we are expecting users to change these allocations...

Not users but certainly administrators.


>
>> Proposed solution:
>> - We will introduce a range check / port range allocation service.
>> There will be one per sipx proxy server and it will be co located with
>> the proxy server. Before a port or port range is allocated, the port
>> range service is consulted. The port allocation service will
>> bind/unbind to that range of ports. If the port has been allocated or
>> if there is a clash with an existing allocation, an error is returned.
>> If there is no error, then the specified range of ports is allocated
>> and recorded. The port allocation service will also be able to return
>> an "ephemeral port" for services that need such ports.
>
> How do we handle servers that do not contain a proxy?

So long as a port allocation service runs there, it can be contacted
at a well known URL. If nothing is answering at the specified URL,
then a check does not happen.

>
> I am thinking that it might be easier to put the allocation service in
> the config server and have it operate at config time, not run time.

Just so long as there is one place to do it. I already manage port
ranges for the sipXrelay and I run a stun client there so I thought it
might be a good candidate. config server is fine too as far as I am
concerned.

Certainly the more that is checked statically, the better. Dynamic
checking is also important; however. This is going to be a bit
problematic using a naive scheme. Say you wanted to change the
external port used by sipxbridge back to what it is currently set at
and restart it, the checking service is going to report a port clash
because clearly that port is being used. Thus we need an algorithm
that defines port range ownership on a per service basis. Not a
problem if the service names are unique.

Another requirement - some ports must be the same across a cluster.
For example, I am assuming that SipXrelay uses the same HTTP port so
by looking at the inbound via at sipxbridge, I know where to contact
its sipxrelay ( in the default case where this is not explicitly
configured in sipxbridge ). So config server needs to check across the
cluster for certain ports.

Ranga

>
> Dale
>
>
>



-- 
M. Ranganathan
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to