On Mon, Jun 9, 2008 at 9:42 AM, Scott Lawrence <[EMAIL PROTECTED]> wrote:

> > I would think that the above would argue for separating the media relay
> > configuration and process management from that of sipXbridge.  The 4.0
> > sipXsupervisor has a mechanism to configure process dependencies, so it
> > can take care of not starting a proxy or a bridge that depends upon a
> > media relay until after it is up if that is needed.

On Mon, 2008-06-09 at 10:24 -0400, M. Ranganathan wrote:

> I am starting to see some advantages in separating the function but I
> have one question - how can the single signaling server ( i.e.
> sipxbridge that talks to ITSP registrars ) know about the various
> instances of media relay ( i.e. which ones are alive, which ones it
> can use etc. ) ?

It should be part of the sipXbridge configuration, and also part of the
proxy configuration.  The configuration of any given sipXbridge or proxy
instance need not be the same as that of other instances.  For example,
each proxy instance is configured to use a different SRV name for the
registry/redirect service so that the internal SRV records can
prioritize them.

> I assume there is some configuration parameter that can tell me at
> least where all the HA instances are running. I can do mutual pinging
> to figure out liveness after system restart. How can I find this
> information?

If we decide that you need it, we'll add it to the sipXbridge
configuration, but see below...

> There can be only one instance of signaling (that talks to external
> registrars). So we need a failover mechanism for that. How shall we do
> this ?

At this point, HA is not a requirement for sipXbridge, so I think this
issue can be deferred until it is.

The 
> Minor: I assume sipXrelay would be a decent name to give such a service.

Well, we should settle on just one name... Woof had started with
'symitron' (or some similar spelling).  I certainly don't insist that
everything we do start with 'sipX'.  


-- 
Scott Lawrence  tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  CTO, Voice Solutions   - Bluesocket Inc. http://www.bluesocket.com/ 
                                           http://www.pingtel.com/

_______________________________________________
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